[CS2113T-T12-2] PayMeBack#31
Conversation
| ## Design | ||
|
|
||
| ### Architecture | ||
| The ***Architecture Diagram*** given above explains the high-level design of the App. |
There was a problem hiding this comment.
yep I agree, better to have atleast a few class diagrams
|
|
||
| When `Parser` calls the `executeExpense` method, it creates an expense object, and also calls the `promptDate` method to set that expense object’s date. `promptDate` calls `isDateValid` to validate user input. | ||
|
|
||
|
|
There was a problem hiding this comment.
Is it possible to add some in this part?
KishorKumar11
left a comment
KishorKumar11
left a comment
There was a problem hiding this comment.
Overall, good job! Explanations are clear and precise, however just need to improve the readability factor 👍🏽
|
|
||
| ### `Expense` Class | ||
| The `Expense` class deals with most functionalities related to adding an expense inside a trip. The sequence diagram below shows how an expense is initialised. | ||
|  |
There was a problem hiding this comment.
Unable to view sequence diagram. Perhaps you could recheck the directory/link?
| The `Parser` class | ||
| - Contains the logic to check user commands and break the input into the necessary contents for other classes to use |
There was a problem hiding this comment.
Perhaps, documentations like this can be followed for the other classes too?
|
|
||
| ## Acknowledgements |
There was a problem hiding this comment.
Adding hyperlinks to subtopics would be a great idea! (like content pointers used in UG)
| The Person Class, | ||
| * Represents an individual that participated in an expense or a whole trip. | ||
| * A user-defined amount of `Person` objects will be created by the user during the create function of the `Trip` Class. | ||
| * Every time an object is created of the `Expense` Class, the user may define the people who were involved in the expense, however the people who are added to the expense must be already a `Person` object in the `Trip` object that the expense was made. | ||
| * One `Person` object who was involved in the expense will then be appointed as the payer of the group, the user will then have to indicate how much (in foreign currency) each of the participating persons spent for that particular expense. This is then stored and updated in each of the respective `Person` object’s `moneyOwed` HashMap, where a positive double refers to how much the person owes the respective Person object (i.e. the key of the HashMap) and a negative double refers to how much the Person object (i.e. the key of the HashMap) owes to that instance of the Person object. | ||
| * Example: If the HashMap = {person2 = 22, person3 = -11} in the person1 object, then person1 owes person2 $22 and person3 owes person1 $11. |
There was a problem hiding this comment.
As a fellow developer, I would like to recommend that the description for each your classes could follow a standard format. This would help the reader easily understand the idea/explanations of the concepts.
| ## Design | ||
|
|
||
| ### Architecture | ||
| The ***Architecture Diagram*** given above explains the high-level design of the App. |
There was a problem hiding this comment.
yep I agree, better to have atleast a few class diagrams
| The ***Architecture Diagram*** given above explains the high-level design of the App. | ||
|
|
||
| Given below is a quick overview of main components and how they interact with each other. | ||
|
|
There was a problem hiding this comment.
You could add an object diagram here to show how the classes interact with one another
| - Prints the information through the terminal. | ||
|
|
||
| ### `Parser` Class | ||
|
|
There was a problem hiding this comment.
A UML class diagram would be helpful here to show the associations used for each command being called here.
| The remaining components are as follows: | ||
|
|
||
| `Ui`: The User Interface of the App | ||
| `Parser`: The command executor |
There was a problem hiding this comment.
Having line breaks here may improve your DG as it makes the DG more readable and easier to understand, and it will be slightly less cluttered.
| and is a container class for the expenses (each expense being represented by an | ||
| instance of the `Expense` class) and persons (each person being represented by an | ||
| instance of the `Person` class) tagged to the trip. | ||
|
|
There was a problem hiding this comment.
Since the Trip class contains many other classes and constructors of the other classes, would a UML diagram here help with the clarity of your DG?
add duplicate detection for new trips + update error message for empty delete
Heavily tested 'help' command, should be ready for PE now
Final iteration
some UG fixes, added some javadoc & author tags
Updated java docs for filter and optimize functions
added man testing for edit trip and summary
Fixed spacing
…into v2.0-WorkingBranch � Conflicts: � docs/DeveloperGuide.md
small update!
Fixed spacing
9 participants
placeholder