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 and hosted on CodingRooms 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:

1. describe each of the SOLID principles,
2. identify when a principle is used in existing code,
3. identify when a principle should be used to improve a piece of code,
4. implement the principle in an existing or new piece of code,
5. use self-explanation to enrich their own learning process, and
6. 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

Schedule

Week	Driving Question(s)	Assignment Due	Suggested Final Project Progress for the Week
1: Overview	What does SOLID-ify cover?		Read over the rubric
2: Self-Explanation	What is Self-Explanation?	“About you” from Overview “Pre-Assessment” from Self-Explanation	Start identifying a coding project to refactor
3: Single Responsibility, Part 1	What is Single Responsibility? How is Single Responsibility applied?	“Self-Explanation of Line 3” from Self-Explanation “Post-Assessment” from Self-Explanation	Identifying a coding project to refactor (Optional) Use self-explanation to go over a class or function in the selected project
4: Single Responsibility, Part 2	Why is Single Responsibility useful?	“Quiz” from Single Responsibility, Part 1	Start identifying code that could benefit from Single Responsibility, documenting refactor options
5: Open-Closed, Part 1	What is Open-Closed? How is Open-Closed applied?	“Refactor” from Single Responsibility, Part 2	Choose the best option from the previously identified options, documenting the reasoning Start implementation
6: Open-Closed, Part 2	Why is Open-Closed useful?	“Quiz” from Open-Closed, Part 1	Start identifying code that could benefit from Open-Closed, documenting refactor options Update options, reasoning for previous refactors as needed Continue implementation
7: Liskov Substitution, Part 1	What is Liskov Substitution? How is Liskov Substitution applied?	“Refactor” from Open-Closed, Part 2	Choose the best option from the previously identified options, documenting the reasoning Continue implementation
8: Liskov Substitution, Part 2	Why is Liskov Substitution useful?	“Quiz” from Liskov Substitution, Part 1	Start identifying code that could benefit from Liskov Substitution, documenting refactor options Update options, reasoning for previous refactors as needed Continue implementation
9: Interface Segregation, Part 1	What is Interface Segregation? How is Interface Segregation applied?	“Refactor” from Liskov Substitution, Part 2	Choose the best option from the previously identified options, documenting the reasoning Continue implementation
10: Interface Segregation, Part 2	Why is Interface Segregation useful?	“Quiz” from Interface Segregation, Part 1	Start identifying code that could benefit from Interface Segregation, documenting refactor options Update options, reasoning for previous refactors as needed Continue implementation
11: Dependency Inversion, Part 1	What is Dependency Inversion? How is Dependency Inversion applied?	“Refactor” from Interface Segregation, Part 2	Choose the best option from the previously identified options, documenting the reasoning Continue implementation
12: Dependency Inversion, Part 2	Why is Dependency Inversion useful?	“Quiz” from Dependency Inversion, Part 1	Start identifying code that could benefit from Dependency Inversion, documenting refactor options Update options, reasoning for previous refactors as needed Continue implementation
13: No Session - Work on Final Project		“Refactor” from Dependency Inversion, Part 2	Choose the best option from the previously identified options, documenting the reasoning Finish implementation Polish written documentation
14: No Session - Course Over		Final Project Due

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
  • Home
  • Getting Started for Learners
  • Privacy Policy
• Policies
  • UNC’s Honor Code
  • UNC’s Policy on Prohibited Harassment and Discrimination
  • UNC’s Plagiarism Tutorial

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

---