forked from se-edu/addressbook-level4
-
Notifications
You must be signed in to change notification settings - Fork 54
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[se-edu#190] Make ReadOnlyAddressBook truly read-only (se-edu#199)
* Remove redundant "get empty address book" methods It seems strange that we have AddressBook#getEmptyAddressBook() and TestUtil#generateEmptyAddressBook() methods, when a simple `new AddressBook()` will give us what we want. * Fully encapsulate UniquePersonList and UniqueTagList within AddressBook ReadOnlyAddressBook declares the following methods: * `UniqueTagList getUniqueTagList();` * `List<Tag> getTagList();` * `UniquePersonList getUniquePersonList();` * `List<ReadOnlyPerson> getPersonList();` As we can see, there is some redundancy; both `getUniqueTagList()` and `getTagList()` conceptually do the same thing, and both `getUniquePersonList()` and `getPersonList()` conceptually do the same thing as well. So, to simplify the API we need to pick one set of APIs: either the ones that return `UniqueXList`, or the ones that return `List<X>`. Going with the API that returns `List<X>` is more beneficial than `UniqueXList`: Lists are widely used throughout our code and the standard library, and thus returning a list would be much more convenient for developers. `UniquePersonList` and `UniqueTagList`, on the other hand, only implement the `Iterable` interface, and are thus slightly more annoying to write code with. However, there is a deeper problem as well: `UniquePersonList` and `UniqueTagList` both contain mutating methods, which violates the contract of `ReadOnlyAddressBook` to provide a read-only view to the address book. We could solve this by introducing `ReadOnlyUniquePersonList` and `ReadOnlyUniqueTagList` interfaces, but as argued above, by virtue of not implementing the `List` interface these objects are more annoying to deal with and thus it is likely better to not return them at all. As such, this commit removes the `getUniqueTagList()` and `getUniquePersonList()` methods. In addition, we also remove all of the methods of `AddressBook` that take a `UniquePersonList` or `UniqueTagList`, thus fully encapsulating these classes within `AddressBook`. This not only solves the contract violation problem as discussed above, it also reduces coupling as users will no longer need to depend directly on `UniquePersonList` and `UniqueTagList` any more. * ModelManager: merge two similar constructors Both ModelManager(AddressBook, UserPrefs) and ModelManager(ReadOnlyAddressBook, UserPrefs) both do exactly the same thing. Let's DRY up the code by merging them into one single constructor. The author notes that the `userPrefs` argument is currently not even used. However, fixing this is outside the scope of this commit. * AddressBook: replace getPersons() with getPersonList() ReadOnlyAddressBook has a getPersonList() method which returns its list of persons as a List<ReadOnlyPerson> AddressBook has a getPersons() method which returns its list of persons as an ObservableList<Person>. Simplify the API by merging these methods together, by making getPersonList() return an ObservableList<ReadOnlyPerson> and removing getPersons(). * ReadOnlyAddressBook: make getTagList() return an ObservableList Even though there are currently no callers that require the return value to be an ObservableList, this is still done for consistency with getPersonList() and to make it easier to implement future UI features such as a listing of all tags. * fixup! Fully encapsulate UniquePersonList and UniqueTagList within AddressBook * fixup! Fully encapsulate UniquePersonList and UniqueTagList within AddressBook
- Loading branch information
Showing
10 changed files
with
169 additions
and
113 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.