improved "OO Design Principles" section of the Design Doc. -ak

1 files changed, 4 insertions, 0 deletions

diff --git a/docs/DesignDoc.md b/docs/DesignDoc.md
index 0a92bac..7f1c457 100644
--- a/docs/DesignDoc.md
+++ b/docs/DesignDoc.md
@@ -167,9 +167,13 @@ In our model tier we have a Need class, a User class, and a UserAuth class. The
 > _**[Sprint 1]** Name and describe the initial OO Principles that your team has considered in support of your design (and implementation) for this first Sprint._
 
 - Law of Demeter: Classes only talk to nearby classes.
+  - This principle is used to ensure that unintended behavior is minimal, by making each class only talk to others that make sense in the scope of the application. For example, the `dashboard` component interacts with the `need-list` and `funding-basket` components because they are needed to display needs on the dashboard, but it does not interact with the `login` or `signup` components, as they are not needed in order to ensure the functionality of the dashboard. These are located in the ViewModel and Model Tiers.
 - Low Coupling: Limit the number of classes connected to each individual class.
+  - We use Low Coupling principles to ensure that only classes related in function are actually interacting with each other. In our Angular setup, classes interact with their respective services instead of sharing the data with other classes. `NeedService` connects to `need-page`, `need-list`, `funding-basket`, and `cupboard`, but the components themselves do not interact with each other. This is more efficient and prevents one component from stalling if another errors. Because the service exclusively handles CRUD operations, it will not cause the connected components to stall if it encounters an error. These examples are located in the ViewModel Tier.
 - Pure Fabrication: Using helper functions to split up larger classes into more managable chunks.
+  - For example, this principle is showcased in our `AuthService`. Instead of having the `UserService` handle user management and user authorization at the same time, we have split the authorization part into a new AuthService class to handle login, while the UserService handles just the CRUD operations pertaining to the user. These classes are located in the ViewModel Tier.
 - Single Responsibility: Each function should only have one function to prevent unintended errors.
+  - This principle is used in our `CupboardController`, as it's only functionality is to connect the front-end and back-end through our REST API. This means that cupboard-related operations are not backlogged by any other classes, which is efficient and prevents unintended behavior in the application. This can be seen in the Model Tier.
 
 > _**[Sprint 2, 3 & 4]** Will eventually address upto **4 key OO Principles** in your final design. Follow guidance in augmenting those completed in previous Sprints as indicated to you by instructor. Be sure to include any diagrams (or clearly refer to ones elsewhere in your Tier sections above) to support your claims._