Skip to content

Latest commit

 

History

History
274 lines (190 loc) · 12.8 KB

LearningOutcomes.md

File metadata and controls

274 lines (190 loc) · 12.8 KB
Raw

Learning Outcomes

After studying this code and completing the corresponding exercises, you should be able to,

  1. Apply Encapsulation [LO-Encapsulation]
  2. Implement a class [LO-ImplementClass]
  3. Follow the Single Responsibility Principle [LO-SRP]
  4. Handle Exceptions [LO-Exceptions]
  5. Use Inheritance to achieve code reuse [LO-Inheritance]
  6. Follow Interface Segregation Principle [LO-ISP]
  7. Use class-level members [LO-ClassLevel]
  8. Use Composition [LO-Composition]
  9. Use Association Classes [LO-AssociationClass]
  10. Use JUnit to implement unit tests [LO-JUnit]
  11. Use TDD [LO-TDD]
  12. Work in a 2KLoC code base [LO-2KLoC]

Apply Encapsulation [LO-Encapsulation]

Exercise: Encapsulate CommandResult class members
  • A member of the CommandResult class is not encapsulated. i.e. it is visible outside the object. Hide it so that it can only be accessed using methods provided.

Implement a class [LO-ImplementClass]

Side readings
Exercise: Split Address into more classes
  • Assume the address is entered in the following format a/BLOCK, STREET, UNIT, POSTAL_CODE
    e.g. a/123, Clementi Ave 3, #12-34, 231534
  • Split the Address class as follows.
  • Update the user guide and tests to match.

Follow the Single Responsibility Principle [LO-SRP]

The Single Responsibility Principle (SRP) states that a class should have only one reason to change. The code given follows SRP to a reasonable extent, but there are places where it can be applied further.

Resources
Exercise: Split TextUi class

The exercise in the LO-ImplementClass section is somewhat related to SRP as well. Here's a slightly more difficult exercise.

  • TextUi class has more than one responsibility. Try to extract out the responsibility of Formatting text for display (e.g. adding decorations) in to a separate class named Formatter.

Handle Exceptions [LO-Exceptions]

Resources
Exercise: Handle 'file deleted' situation
  • The current code does not handle the situation where the user deletes the storage file while the AddressBook program is running. Use exceptions to handle that situation.

Use Inheritance to achieve code reuse [LO-Inheritance]

Note how the Command class contains some code that is reused by some of its child classes. By defining *Command classes as child classes of Command, we have avoided having to duplicate those methods in multiple *Command classes.

Exercise: Extract a Contact class
  • Extract commonalities from Phone, Email and Address classes into a parent class called Contact.

Follow Interface Segregation Principle [LO-ISP]

The Interface-Segregation Principle (ISP) states that no client should be forced to depend on methods it does not use.

Note how the Person class implements the ReadOnlyPerson interface so that clients who don't need write access to Person objects can access Person objects through the ReadOnlyPerson interface instead.

Exercise: Add a Printable interface

  • Add a Printable interface as follows.

  • Override the getPrintableString in classes Name, Phone, Email, and Address so that each produces a printable string representation of the object. e.g. Name: John Smith, Phone: 12349862

  • Add the following method in a suitable place of some other class. Note how the method depends on the Interface.

    /**
  * Returns a concatenated version of the printable strings of each object.
  */
String getPrintableString(Printable... printables){

    The above method can be used to get a printable string representing a bunch of person details. For example, you should be able to call that method like this:

    //p is a Person object
return getPrintableString(p.getPhone(), p.getEmail(), p.getAddress());

Use class-level members [LO-ClassLevel]

Note how some of the variables and methods are declared static. That means they are class-level members rather than instance-level members.
e.g.
Main.VERSION, Name.EXAMPLE, Utils.isAnyNull(...)

Exercise: Add class-level members
  • Convert the Parser::parseCommand(...) method (i.e. the parseCommand() method of the Parser class) to a class-level method. Note how this method can be either class-level or instance-level.
  • Note how the setTags method of the Person class cannot be converted to a class-level method.
  • Add an instance-level member int sequenceNumber and a class-level variable int nextSequenceNumber to the Person class. Using these two variables, ensure that each Person object has a unique sequence number that indicates the order in which Person objects were created. e.g.
    • Adam is the first Person object to be created. It is assigned sequence number 1.
    • Ben and Charlie are created next, and assigned 2 and 3 respectively.
    • Ben is deleted.
    • Daisy is added next and is given sequence number 4.

Use Composition [LO-Composition]

Note the following examples of composition (filled diamond):

Whole Parts
AddressBook UniquePersonList UniqueTagList
Person Name Phone Email Address

Contrast with these examples of aggregration (empty diamond):

Container Contained
UniquePersonList Person
UuniqueTagList Tag

Use Association Classes [LO-AssociationClass]

The current design does not have any association classes.

Exercise: Add an Association Class Tagging

  • Assume the following:

    1. There are commands to add and remove tags to a person in the address book.
    2. When the AddressBook program exits, it should print out a list of all the tags added/deleted during that session. e.g.
    + Jake Woo [friend]
- Jake Woo [colleague]
+ Jean Wong [client]

  • To support (ii) above, implement an Association Class called Tagging as given in the diagram below.
    Each Tagging object will represent an adding or deleting of a tag for a specific person that happened during that session.

    Note that if the list of Taggings is kept as a class-level variable the Tagging class, the diagram would be like this:

Use JUnit to implement unit tests [LO-JUnit]

Note the test/seedu/addressbook/parser/ParserTest.java class that users Junit to implement automated unit tests.

Resources
Side readings
Exercise: Write unit tests for the Utils class
  • First, make sure you know how to run JUnit tests by running the ParserTest.java. Instructions are in the Developer Guide.
  • Add a test/seedu/addressbook/common/UtilsTest.java containing JUnit tests for the Utils class.

Use TDD [LO-TDD]

It's recommended you do [LO-JUnit] before attempting TDD.

Resources
Side readings
Exercise: Add a method in TDD fashion

  • Add the following method to the Name class. Use the TDD technique to add the method. Commit after each step.

    /**
  * Returns true of the other name is very similar to this name.
  * Two names are considered similar if ...
  */
  public boolean isSimilar(Name other) { ... }

  • You may define 'similar' as you see fit. Make sure the definition covers scenarios where other name is null, in a different case, in a different order, is a subset/superset, etc.
    e.g. John K Smith John K SMITh John Smith Smith, John K

  • Don't forget to refactor the method to improve its code quality at the end.

Work in a 2KLoC code base [LO-2KLoC]

Exercise: Enhance AddressBook

Add a feature to AddressBook. Here are some suggestions.

  • An Edit command
  • A Sort command
  • List all persons automatically after an add or delete command
  • Any other enhancement that you might see fit