Courses/SOLID-ify: Difference between revisions
Line 105: | Line 105: | ||
'''65''' | '''65''' | ||
|} | |} | ||
{| class="wikitable" | |||
!colspan="5"| 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) | |||
|- style="vertical-align:top;" | |||
| | |||
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. | |||
|} | |||
{| class="wikitable" | |||
!colspan="5"| 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) | |||
|- style="vertical-align:top;" | |||
| | |||
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 | |||
|} | |||
{| class="wikitable" | |||
!colspan="5"| Rubric 3: Quality refactor demonstration for each principle | |||
|- | |||
! Exemplary (6 pts) !! Proficient (4.75 pts) || Emerging (3 pts) || Insufficient (1 pt) || Absent (0 pts) | |||
|- style="vertical-align:top;" | |||
| | |||
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 == | |||
----- | ----- |
Revision as of 12:58, 27 March 2024
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
- ↑ 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.