Merge 3730a58 into 84827cb

docs/DeveloperGuide.adoc

@@ -234,26 +234,26 @@ Classes used by multiple components are in the `seedu.addressbook.commons` packa
 This section describes some noteworthy details on how certain features are implemented.
 
 // tag::patient_kyler[]
-=== Patient Management Feature
-==== Current Implementation: Storing Patient's Information
+=== Patient Management
+==== Patient Feature
 
 The `Patient` class represents patients for our users on TeethHub.
 It extends `Person` with more patient-specific attributes, as well as methods.
 Various methods are also overridden in order for them to work appropriately with the new `Patient` class.
 
 The following class diagram summarizes the new `Patient` class, which extends from `Person`:
 
-image::PatientClassDiagram.png[width="800]
+image::PatientClassDiagram.png[width="800"]
 
-==== Current Implementation: Patient's Dental Records
+==== Dental Records Feature
 
 The `Record` class represents a dental record of a patient. Each `Patient` class has an list of `Record` as an attribute.
 
 The `Record` class is purposely implemented to be similar to that of `Person`.
 Just like person, record has associate classes for specific operations, such as storage.
 This ensures that the processing of records is streamlined with `Patient`, which extends `Person`.
 
-==== Current Implementation: Interface to interact with Patient's Dental Records
+==== Records Mode Feature
 
 The current implementation to view a specified patient's dental records uses the `goto` command.
 
@@ -298,7 +298,7 @@ The following activity diagram summarizes what happens when a user executes the
 image::GotoActivityDiagram.png[width="800"]
 {nbsp}
 
-==== Current Implementation: Representing Patient's Teeth
+==== Patient's Teeth Feature
 
 The `Teeth` class represents patients' teeth for our users on TeethHub.
 It consist of an array of `Tooth` objects, which represents the individual tooth of patients.
@@ -324,7 +324,7 @@ The following class diagram summarizes the `Teeth` class, which is a composition
 image::TeethClassDiagram.png[width=""]
 {nbsp}
 
-==== Current Implementation: Automatically Generated Tags
+==== Automatically Generated Tags Feature
 
 There are only two types of tags that are valid in the `Patient` class.
 They are `StatusTag` and `TeethTag`.
@@ -344,7 +344,7 @@ image::StatusTagActivityDiagram.png[width=""]
 [NOTE]
 Since only permanent teeth is supported by TeethHub at the moment, `TeethTag` will always show "Permanent Teeth".
 
-==== Current Implementation: Dentist Information
+==== Dentist Feature
 
 Following the single user policy, TeethHub only prompts the user once to acquire his or her name, which will then be used when creating new dental records for patients.
 
@@ -354,7 +354,7 @@ Currently, the application prompts the user for his or her name during his or he
 Currently, the dentist's name is stored in a `.txt` file in TeethHub.
 It is possible for users to change their name from the `.txt` file, although they are not encouraged to do so.
 
-==== Current Implementation: Other Relevant Commands
+==== Other Relevant Features
 
 We have also created new commands that will facilitate the `Patient` class.
 
@@ -373,73 +373,71 @@ The commands below can only be executed after a patient is specified via the `Go
 
 ===== Aspect: Creating the Patient class
 
-* **Alternative 1 (current choice):** Create the `Patient` class by extending it from `Person`.
-** Pros: It is intuitive, as it is logical that all patients are persons as well.
+* **Current implementation:** Create the `Patient` class by extending it from `Person`.
+** **Alternative:** Create the `Patient` class from the bottom-up.
+*** Alternative Pros: As `Patient` will not be a subclass of any other class, it will be less affected by changes in other classes.
+*** Alternative Cons: All existing classes and methods which currently work with `Person` needs to be re-written to work with the new `Patient` class.
+Attributes and methods cannot be reused, and must be re-implemented.
+Lastly, polymorphism cannot be applied in cases where there is a need to deal with both persons and patients.
+** **Choice Justification:** It is intuitive, as it is logical that all patients are persons as well.
 The code from `Person` can be reused in `Patient` through inheritance, and all existing classes and methods which work with `Person` will also work with `Patient`.
 Most importantly, it allows us to make use of the object-oriented programming principles we learnt in class.
 We assume that the Open-Closed Principle is applied on the `Person` class.
-** Cons: Any changes to `Person` may affect `Patient`.
-* **Alternative 2:** Create the `Patient` class from the bottom-up.
-** Pros: As `Patient` will not be a subclass of any other class, it will be less affected by changes in other classes.
-** Cons: All existing classes and methods which currently work with `Person` needs to be re-written to work with the new `Patient` class.
-Attributes and methods cannot be reused, and must be re-implemented.
-Lastly, polymorphism cannot be applied in cases where there is a need to deal with both persons and patients.
 
 ===== Aspect: Picking the appropriate data structure to store dental records
 
-* **Alternative 1 (current choice):** Store the records using a list.
-** Pros: It is easy to understand, which is crucial for collaborative programming as other programmers may require accessing the records in the list.
+* **Current implementation:** Store the records using a list.
+** **Alternative:** Store the records using a hash table.
+*** Alternative Pros: It gives the fastest time complexity if a record search is required. It runs in O(1) time.
+*** Alternative Cons: It can be challenging for collaborators to understand, which can be detrimental for collaborative programming.
+It also creates an extra layer of complexity in order to display the stored records in the order they were first stored in the application by our users.
+** **Choice Justification:** It is easy to understand, which is crucial for collaborative programming as other programmers may require accessing the records in the list.
 It can also save new records in the order of when they are added, from most recent to oldest, simply using `List.add(0, Record)`.
-** Cons: If the list gets long over time, it might cause additional waiting time for our users when they would to search for a specific record.
+However, if the list gets long over time, it might cause additional waiting time for our users when they would to search for a specific record.
 This is because a linear search in a list is of O(n) time complexity.
- * **Alternative 2:** Store the records using a hash table.
- ** Pros: It gives the fastest time complexity if a record search is required. It runs in O(1) time.
- ** Cons: It can be challenging for collaborators to understand, which can be detrimental for collaborative programming.
- It also creates an extra layer of complexity in order to display the stored records in the order they were first stored in the application by our users.
 
 ===== Aspect: How the goto command executes
 
-* **Alternative 1 (current choice):** Use a static variable to store the specified patient, with a public getter method, and a static boolean that denotes the current list viewing mode.
-** Pros: This is relatively easy to implement and understand. Furthermore, other classes can easily access the current specified patient, and the current list viewing mode.
-** Cons: May cause complications if MainWindow is no longer a singleton class.
-* **Alternative 2:** Save the specified patient and list viewing mode as an instance variable of MainWindow.
-** Pros: Will work properly even if MainWindow is no longer a singleton class.
-** Cons: Challenging to implement as major revamp is required to most existing classes and tests.
+* **Current implementation:** Use a static variable to store the specified patient, with a public getter method, and a static boolean that denotes the current list viewing mode.
+** **Alternative:** Save the specified patient and list viewing mode as an instance variable of MainWindow.
+*** Alternative Pros: Will work properly even if MainWindow is no longer a singleton class.
+*** Alternative Cons: Challenging to implement as major revamp is required to most existing classes and tests.
 All new classes which wish to access the specified patient or list viewing mode will need to take in a reference to the MainWindow instance.
+** **Choice Justification:** This is relatively easy to implement and understand. Furthermore, other classes can easily access the current specified patient, and the current list viewing mode.
+However, it may cause complications if MainWindow is no longer a singleton class.
 
 ===== Aspect: Data structure to support the goto command
 
-* **Alternative 1 (current choice):** Use a patient variable to store the patient specified by the command.
-** Pros: An intuitive solution, as the specified patient is stored as an exact same class as a patient.
+* **Current implementation:** Use a patient variable to store the patient specified by the command.
+** **Alternative:** Create a new immutable patient variable to store the specified patient.
+*** Alternative Pros: Ensures the the specified patient cannot be edited by other classes or methods.
+*** Alternative Cons: Major changes to the patient class would require the immutable patient class to be changed too.
+Furthermore, every time any record of the specified patient is modified, a new immutable patient needs to be created to update the currently stored immutable patient.
+** **Choice Justification:** An intuitive solution, as the specified patient is stored as an exact same class as a patient.
 Additionally, attributes of the specified patient can be accessed just like any other patient class.
 Changes to the patient class does not significantly affect the goto command.
-** Cons: The patient class is mutable, and accidental changes to its attributes by other classes or methods can occur.
-* **Alternative 2:** Create a new immutable patient variable to store the specified patient.
-** Pros: Ensures the the specified patient cannot be edited by other classes or methods.
-** Cons: Major changes to the patient class would require the immutable patient class to be changed too.
-Furthermore, every time any record of the specified patient is modified, a new immutable patient needs to be created to update the currently stored immutable patient.
+However, the patient class is mutable, and accidental changes to its attributes by other classes or methods can occur.
 
 ===== Aspect: Data structure for Teeth
 
-* **Alternative 1 (current choice):** Create a `Tooth` object representing a tooth, and use an array to store a list of tooth which will represent the teeth of patients.
-** Pros: An straightforward object-oriented solution and easy to understand by other collaborating programmers who are familiar with object-oriented programming.
-** Cons: `Tooth` and `Teeth` objects, as well as their relevant methods takes a significant amount of time to be created. They will also require proper test cases to be implemented.
-* **Alternative 2:** Create an integer array representing teeth. Each integer value in the array indicates the status of a tooth.
-** Pros: Simplest to implement.
-** Cons: Can be hard to understand by other programmers as integers are used to represent teeth statuses. Additionally, this is violating object-oriented principles.
+* **Current implementation:** Create a `Tooth` object representing a tooth, and use an array to store a list of tooth which will represent the teeth of patients.
+** **Alternative:** Create an integer array representing teeth. Each integer value in the array indicates the status of a tooth.
+*** Alternative Pros: Simplest to implement.
+*** Alternative Cons: Can be hard to understand by other programmers as integers are used to represent teeth statuses. Additionally, this is violating object-oriented principles.
+** **Choice Justification:** An straightforward object-oriented solution and easy to understand by other collaborating programmers who are familiar with object-oriented programming.
+However, `Tooth` and `Teeth` objects, as well as their relevant methods takes a significant amount of time to be created. They will also require proper test cases to be implemented.
 
 ===== Aspect: Implementing the Dentist class
 
-* **Alternative 1 (current choice):** Use a patient variable to store the patient specified by the command.
-** Pros: An intuitive solution, as the specified patient is stored as an exact same class as a patient.
+* **Current implementation:** Use a patient variable to store the patient specified by the command.
+** **Alternative:** Create a new immutable patient variable to store the specified patient.
+*** Alternative Pros: Ensures the the specified patient cannot be edited by other classes or methods.
+*** Alternative Cons: Major changes to the patient class would require the immutable patient class to be changed too.
+Furthermore, every time any record of the specified patient is modified, a new immutable patient needs to be created to update the currently stored immutable patient.
+** **Choice Justification:** An intuitive solution, as the specified patient is stored as an exact same class as a patient.
 Additionally, attributes of the specified patient can be accessed just like any other patient class.
 Changes to the patient class does not significantly affect the goto command.
-** Cons: The patient class is mutable, and accidental changes to its attributes by other classes or methods can occur.
-* **Alternative 2:** Create a new immutable patient variable to store the specified patient.
-** Pros: Ensures the the specified patient cannot be edited by other classes or methods.
-** Cons: Major changes to the patient class would require the immutable patient class to be changed too.
-Furthermore, every time any record of the specified patient is modified, a new immutable patient needs to be created to update the currently stored immutable patient.
-
+However, the patient class is mutable, and accidental changes to its attributes by other classes or methods can occur.
 // end::patient_kyler[]
 
 // tag::undoredo[]