Courses/SOLID-ify
Course Description
Welcome to SOLID-ify! SOLID-ify is a free, online, video-driven, asynchronous 14-week course with 12 modules offered by DevCred[1] and hosted on CodingRooms[2] that teaches a software development concept called the SOLID principles. SOLID is a mnemonic of the following software design principles: single-responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion. Application of the SOLID design principles makes software code more readable, maintainable, extensible, and testable.
In addition to the SOLID principles, this course teaches a “Learning to Learn” concept called “Self-Explanation”. Self-explanation can be broken down into six strategies: comprehension monitoring, paraphrasing, elaboration, logical inferences, predictions and bridging. Each of these strategies can help learners think about different aspects of their interactions with the material they are learning, leading to deeper understanding.
Target Audience
This course is intended for apprentice or journeyman software developers experienced with Java 8 or higher who would like to write higher quality code for individual skill enhancement or professional advancement.
Prerequisites
Learners will need reliable internet access and a CodingRooms account. Additionally, learners will need working knowledge of Java 8 or higher. It is recommended that learners also have a Java coding project they would like to improve, but this is not required.
Technology
SOLID-ify is hosted on CodingRooms. All course material is accessible via CodingRooms and all assignments are to be turned in via CodingRooms.
To get started with CodingRooms, refer to their Getting Started guide for learners. Please see their privacy policy regarding data and usage.
Instructor
My name is Emily Trabert and I’m a Computer Science instructional designer, instructor, and software development engineer with over 8 years of professional experience. I love teaching and learning equally and I’m excited to share practical advice from my career to learners looking to strengthen the quality of their code.
Course Objectives
After this course, learners will be able to:
- describe each of the SOLID principles,
- identify when a principle is used in existing code,
- identify when a principle should be used to improve a piece of code,
- implement the principle in an existing or new piece of code,
- use self-explanation to enrich their own learning process, and
- describe the difference working in code bases that do and don’t follow these principles.
Course and Instructional Activities
The course is comprised of video instruction and project-based learning. The first module is an overview of the course, covering the structure of the course and giving learners a chance to introduce themselves. The second module covers self-explanation. In addition to the video, there is a pre-video assessment, a post-video assessment, and a written assignment.
The third through twelfth modules cover the SOLID principles. Each principle has two modules, each of which continuously builds on a course-long working example project. The first module introduces a requirement for the code and the principle, then uses the principle to make a change to the working example. The module ends with a multiple-choice quiz. The second module introduces a requirement for the code, then teaches the learners the utility of the principle, then uses the principle to make a change to the working example. Learners then add a new feature to two existing code bases, one which follows the principle and one which does not. Learners then write a short reflection comparing their experience working in each code base.
At the end of the course, learners will complete and turn in a final coding project. As a base, learners have the option of refactoring their own code from another project, or implementing new features to the course-long running example. Learners will then write a short paper identifying several different implementation options for an assigned change while outlining the pros and cons of each implementation using the SOLID principles as guidelines. Learners will then select one of the options and implement it. Learners will turn in the base code, the refactored code, and a written documentation.
Final Project Examples
The course-long working example project follows the development of a dog washing company. If a learner chooses to implement a new feature on this code base, some features that could be added a part of the final project include but are not limited to:
- Appointment record: how might you show all upcoming and past appointments for a dog?
- Recurring appointments: how might you schedule a recurring appointment for a dog?
- Multiple dogs: currently a client can only have one dog - how would you change the program to keep all existing functionality while supporting multiple dogs?
- Discounts: how might you handle punch cards (buy 10 services, get the 11th service) or referrals (if a client refers a new client who books an appointment, the referring client gets 10% off the next service)?
- Availability: how might you handle shifts and getting available employees for a given date/time?
Assignments
| Description | Objectives | Points |
|---|---|---|
| Overview: About You | 0 | |
| Self-Explanation: Pre-Assessment | 5 | 0 |
| Self-Explanation: Self-Explanation of Line 3 | 5 | 5 |
| Self-Explanation: Post-Assessment | 5 | 5 |
| Single Responsibility, Part 1: Quiz | 1 2 3 5 | 5 |
| Single Responsibility, Part 2: Refactor | 4 6 | 5 |
| Open-Closed, Part 1: Quiz | 1 2 3 5 | 5 |
| Open-Closed, Part 2: Refactor | 4 6 | 5 |
| Liskov Substitution, Part 1: Quiz | 1 2 3 5 | 5 |
| Liskov Substitution, Part 2: Refactor | 4 6 | 5 |
| Interface Segregation, Part 1: Quiz | 1 2 3 5 | 5 |
| Interface Segregation, Part 2: Refactor | 4 6 | 5 |
| Dependency Inversion, Part 1: Quiz | 1 2 3 5 | 5 |
| Dependency Inversion, Part 2: Refactor | 4 6 | 5 |
| Final Project | 1 3 4 6 | 65 |
|
Total |
125 |
All assignments, with the exception of the final project, are graded on task completion; learners get full credit for taking quizzes and submitting refactors.
Final Project Rubrics
Final projects that do not include all three components (base code, refactor, and written documentation) will receive a 0. Additionally, if the refactor code is not clearly based on the base code, the final project will also receive a 0. This may seem harsh, but it is not sufficiently possible to determine improvement and application of the SOLID principles without meeting these two conditions. Learners are not graded on the quality of the base code.
| Description | Rubric | Total Possible Points |
|---|---|---|
| Written documentation contains 2 or more areas of improvement with 2 or more refactor options for areas of improvement for each of the 5 SOLID principles | 5 x Rubric 1 | 15 |
| Written documentation selects 1 option for area of improvement and provides justification that option for each of the 5 SOLID principles | 5 x Rubric 2 | 20 |
| Refactor has 2 or more quality instances of implementing each of the 5 SOLID principles | 5 x Rubric 3 | 30 |
|
Total |
65 |
| Rubric 1: Written documentation refactor options for each principle | ||||
|---|---|---|---|---|
| Exemplary (3 pts) | Proficient (2.75 pts) | Emerging (1.5 pts) | Insufficient (0.25 pt) | Absent (0 pts) |
|
Written documentation has 2 or more identified areas of improvement for this principle. Written documentation provides 2 or more reasonable refactor options for each area of improvement, with explicit justification for each option. |
Written documentation has 2 or more identified areas of improvement for this principle. Written documentation provides 2 or more reasonable refactor options for each area of improvement. |
Written documentation has 1 identified area of improvement for this principle. Written documentation provides 2 or more reasonable refactor options for this area. |
Written documentation has 1 identified area of improvement for this principle. Written documentation provides less than 2 refactor options for this area, or written documentation provides 2 or more refactor options for this area that are not reasonable or not logical. |
Written documentation has no identified areas of improvement for this principle. |
| Rubric 2: Written documentation on selected refactor option for each principle | ||||
|---|---|---|---|---|
| Exemplary (4 pts) | Proficient (3.5 pts) | Emerging (2.25 pts) | Insufficient (0.5 pt) | Absent (0 pts) |
|
Written documentation indicates which refactor option is chosen and provides strong, clear justification for the choice for 2 or more areas of improvement for this principle |
Written documentation indicates which refactor option is chosen and provides justification for the choice for 2 or more areas of improvement for this principle |
Written documentation indicates which refactor option is chosen and provides justification for the choice for 1 area of improvement for this principle |
Written documentation indicates which refactor option is chosen but provides weak or no justification for the choice |
Written documentation does not indicate any refactor options chosen for this principle |
| Rubric 3: Quality refactor demonstration for each principle | ||||
|---|---|---|---|---|
| Exemplary (6 pts) | Proficient (4.75 pts) | Emerging (3 pts) | Insufficient (1 pt) | Absent (0 pts) |
|
Refactor has 2 or more instances implementing this principle, at least 1 of which demonstrates substantial improvement to code quality |
Refactor has 2 or more instances implementing this principle, demonstrating improvement to code quality |
Refactor has 1 instance implementing this principle, demonstrating improvement to code quality |
Refactor has 1 or more trivial instances implementing this principle, which do not demonstrate improvement to code quality |
Refactor has no instances implementing this principle |
Policies
Attendance
Since this course is asynchronous and online, attendance is not applicable. However, it is expected learners will watch the provided videos, turn in assignments on time, and reach out to the instructor when help is needed.
Grading Policy
No late work will be accepted unless prior approval is obtained. Grades are the total points earned divided by the total possible points.
Honor Code
This course follows UNC’s Honor Code.
Additionally, learners are not permitted to upload any content from this course to the web in any form, including but not limited to Stackoverflow, Chegg, Course Hero, Coursera, Google Drive, etc. If learners post this course content, they may be violating DevCred’s intellectual property rights. In utilizing web sources to upload or download course content, learners risk violating the Honor Code.
However, in the spirit of supporting open source access, following the completion of this course, learners are encouraged to post their work in GitHub, GitLab, or another source control website to support others’ learning and receive feedback.
Syllabus Changes
The instructor reserves the right to make changes to any part of the syllabus. Changes will be announced as early as possible.
Harassment and Discrimination
This course follows UNC’s Policy on Prohibited Harassment and Discrimination, which prohibits harassment and discrimination on the basis of an individual’s age, color, disability, gender, gender expression, gender identity, genetic information, race, national origin, religion, sex, sexual orientation, or veteran status.
Accessibility
Adapted from UNC’s Accessibility Syllabus Statement.
Reasonable accommodations, including resources and services, for learners with disabilities, chronic medical conditions, a temporary disability or pregnancy complications resulting in difficulties with accessing learning opportunities are available. Please reach out to the instructor.
Inclusivity and Diversity
All materials and activities are intended to be respectful of diversity in individual’s age, color, disability, gender, gender expression, gender identity, genetic information, race, national origin, religion, sex, sexual orientation, veteran status, socioeconomic status, and culture. It is expected that the instructor and the learners will maintain this standard. If there are any questions, comments, or concerns, please reach out to the instructor.
Compiled Resource Links
- Coding Rooms
- Policies
References
Martin, R. C. (2008). Clean Code : A Handbook of Agile Software Craftsmanship. http://ci.nii.ac.jp/ncid/BA87924669
Martin, R. C. (2014, May 8). The Single Responsibility Principle. The Clean Code Blog. Retrieved June 26, 2023, from https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Meyer, B. (1988). Object-oriented Software Construction. Prentice Hall.
Overview (Java Platform SE 8 ). (2023, April 5). https://docs.oracle.com/javase/8/docs/api/overview-summary.html
- ↑ DevCred provides non-traditionally-trained aspiring software developers with a valuable credential that demonstrates to recruiters and employers that they have the skills needed to succeed in entry-level software development positions. Learn more at https://dev-cred.com/
- ↑ CodingRooms is a code-focused learning management system.