Week 5 - Outcomes

Design:

Supplmentary → Principles →

Single Responsibility Principle

Single Responsibility Principle (SRP): A class should have one, and only one, reason to change. _{-- Robert C. Martin}

If a class has only one responsibility, it needs to change only when there is a change to that responsibility.

📦 Consider a TextUi class that does parsing of the user commands as well as interacting with the user. That class needs to change when the formatting of the UI changes as well as when the syntax of the user command changes. Hence, such a class does not follow the SRP.

An explanation of the SRP from www.oodesign.com
Another explanation (more detailed) by Patkos Csaba
A book chapter on SRP - A book chapter on SRP, written by the father of the principle itself Robert C Martin.

Acceptable: Evidence of having used SRP in some project.

Suggested: Do the exercise in [Addressbook-Level2: LO-SRP]

Submission: Create a PR against Addressbook-Level2. Only clean PRs (i.e. free of unrelated code modifications) will be accepted.

Implementation:

Requirements:

Other:

This LO requires coordination and cooperation among team members. It also requires a few days to complete; we recommend that you start it early in the week rather than just before the tutorial day.

💡 Those who failed to produce working code at 1KLoC milestone (in week 3) can recover the lost marks by doing two enhancements at this milestone.

💡 When working with existing code, a safe approach is to change the code in very small steps, each resulting in a verifiable change without breaking the app. For example, when adding a new sort command, the first few steps can be,

Teach the app to accept a sort command but ignore it.
Next, teach the app to direct the sort command to an existing command e.g. sort command simply invokes the list command internally.
Add a SortCommand class but make it simply a copy of the the existing ListCommand. Direct the sort command to the new SortCommand.
...

💡 Note that you can reuse the code you write here in your final project, if applicable.

Individual component:

You can omit this individual component if you have worked with a code base that meets the following criteria:

more than 2KLoC of the code base was written by other developers
your code included automated tests
your code was contributed via a proper revision control workflow e.g. pull requests

Requirements: Do an enhancement to [AddressBook - Level2] e.g. add a new command. It can be the same enhancement you did to AddressBook Level1 (at the 1KLoC milestone in week 3). The size of the enhancement does not matter but you must,

update the User Guide
update existing tests and add new tests if necessary, for both JUnit tests and I/O tests
follow the coding standard
follow the OOP style

Optional but encouraged:

Update the Developer Guide

Submission: Create a PR against Addressbook-Level2. Only clean PRs (i.e. free of unrelated code modifications) will be accepted.

Team component:

The team component is to be done by all members, including those who were allowed to omit the individual component.

Review PRs created by team members in the Individual Component above i.e. add review comments in the PR created against module repo. You can either give suggestions to improve, or ask questions to understand, the code written by the team member.
Requirements: Try to ensure that each PR reviewed by at least one team member and each team member's PR is reviewed by at least one other team member.
Submission: Just update PR created in the individual component by adding comments/commits to it.