Merge pull request #322 from AlyssaPng/branch-docs-final

Edit DG implementation

docs/DeveloperGuide.md

@@ -221,7 +221,7 @@ The following activity diagram summarises what happens the user executes a sched
 
 <img src="images/ScheduleActivityDiagram.png" width="400"/>
 
-**Design Considerations**
+#### **Design Considerations**
 
 **Aspect: How to implement appointment for Person**
 
@@ -295,14 +295,14 @@ The following activity diagram illustrates how the complete operation is execute
 
 ### Gather Emails Feature
 
-The **Gather Emails** feature in our software system is designed to efficiently collect email addresses. This feature is facilitated by the `GatherCommand` and `GatherCommandParser`. Below is the class diagram of the gather emails feature.
+The **Gather Emails** feature in our software system is designed to efficiently collect email addresses. This feature is facilitated by the `GatherCommand` and `GatherCommandParser`. Below is the class diagram of the `gather emails` feature.
 
 ![GatherClassDiagram](images/GatherClassDiagram.png)
 
 #### Implementation Overview
 
-The `GatherCommand` is initiated by the `GatherCommandParser`. The `GatherCommandParser` checks for the prefixes `fp/` or `t/` in the user's input and creates either a `GatherEmailByFinancialPlan` or `GatherEmailByTag` object respectively.
-Both `GatherEmailByFinancialPlan` or `GatherEmailByTag` implements the `GatherEmailPrompt` interface.
+The `GatherCommand` is initiated by the `GatherCommandParser`. The `GatherCommandParser` parses the arguments and creates either a `GatherEmailByFinancialPlan` or `GatherEmailByTag` object respectively.
+Both `GatherEmailByFinancialPlan` or `GatherEmailByTag` implements the `GatherEmailPrompt` interface. 
 
 The `GatherCommand` takes in the `GatherEmailPrompt` object and passes it into the current `Model`, subsequently interacting with the `AddressBook` class. 
 The `GatherCommand#execute()` executes the gather operation by calling `Model#gatherEmails(GatherEmailPrompt prompt)`. 
@@ -319,27 +319,27 @@ The `UniquePersonsList` class maintains a list of unique persons. The `UniquePer
 
 Depending on the type of `GatherEmailPrompt`, the method above triggers either: 
 
-- `Person#gatherEmailsContainsTag(String prompt)` —  Checks if the given prompt is a substring of any Tag names in the `Set<Tag>` of the current person. 
-- `Person#gatherEmailsContainsFinancialPlan(String prompt)` —  Checks if the given prompt is a substring of any Financial Plan names in the `Set<FinancialPlan>` of the current person.
+- `Person#gatherEmailsContainsTag(String prompt)` —  Checks if the given prompt is a substring of any `Tag` names in the `Set<Tag>` of the current person. 
+- `Person#gatherEmailsContainsFinancialPlan(String prompt)` —  Checks if the given prompt is a substring of any `FinancialPlan` names in the `Set<FinancialPlan>` of the current person.
 
-These methods internally utilize `Tag#containsSubstring(String substring)` and `FinancialPlan#containsSubstring(String substring)`, respectively. These substring comparisons are performed in a case-insensitive manner by converting both the prompt and the financial plan/tag names to lowercase before the check.
-This is to make gathering of emails more convenient and flexible. 
+These methods internally utilize `Tag#containsSubstring(String substring)` and `FinancialPlan#containsSubstring(String substring)`, respectively. These substring comparisons are performed in a case-insensitive manner by converting both the prompt and the `FinancialPlan` or `Tag` names to lowercase before the check.
+By allowing partial input, users can efficiently find email addresses associated with lengthy `Tag` or `FinancialPlan` names. The case-insensitive approach enhances user-friendliness, ensuring consistent and reliable results, regardless of input case.  
 
-Currently, we only allow gathering emails by `FinancialPlan` and `Tag` as these are the more likely to be searched to gather emails by. However, additional classes implementing the `GatherEmailPrompt` interface can be added to enable the gathering of emails based on a broader range of fields.
+Currently, we only allow gathering emails by `FinancialPlan` and `Tag` fields as these are the more likely to be searched to gather emails by. However, additional classes implementing the `GatherEmailPrompt` interface can be added to enable the gathering of emails based on a broader range of fields.
 
-The following sequence diagram shows how the gather emails by financial plan operation works:
+The following sequence diagram shows how the gather emails by `FinancialPlan` field operation works:
 
 ![GatherSequenceDiagram2](images/GatherSequenceDiagram2.png)
 
 #### Design Considerations
 
 **Aspect: How many inputs to accept**
-* **Alternative 1 (Current Choice):** User can only search by one Financial Plan or Tag.
+* **Alternative 1 (Current Choice):** User can only search by one `FinancialPlan` or `Tag`.
   * **Pros:** Easy to implement. Limits the potential for bugs.
   * **Cons:** Limited filtering options.
 
-* **Alternative 2:** User can search by multiple Financial Plans or Tags.
-  * **Pros:** More flexible (e.g. gathering by a combination of financial plans and tags).
+* **Alternative 2:** User can search by multiple `FinancialPlan` and `Tag` fields.
+  * **Pros:** More flexible (e.g. gathering by a combination of `FinancialPlan` and `Tag`).
   * **Cons:** Introduces more complexity and requires additional error handling.
 
 
@@ -388,7 +388,7 @@ searched fields, but extending the feature to search in other fields is possible
     * Cons: Less flexible, slightly more difficult to implement.
 
 **Aspect: How to implement `CombinedPredicate`**
-* **Alternative 1 (current choice):** Use varargs and a common interface.
+* **Alternative 1 (current choice):** Use `varargs` and a common interface.
     * Pros: More flexible in usage while still testable.
     * Cons: More difficult to modify and the check for equality can be defeated with enough effort.