Updated design doc and minor adjustment to cupboardDAO

2 files changed, 8 insertions, 6 deletions

diff --git a/docs/DesignDoc.md b/docs/DesignDoc.md
index 2c2ad2e..c1b76fe 100644
--- a/docs/DesignDoc.md
+++ b/docs/DesignDoc.md
@@ -130,6 +130,8 @@ This section describes the application domain.
 > can discuss the more important domain entities and their relationship
 > to each other._
 
+![alt text](domain-model.png)
+
 Each user views 1 cupboard which can contain 0 or more needs. They can take 1 or more needs and put them in their funding basket which they can then check out. Each user has 1 funding basket. 1 manager will manage the 1 cupboard, add, removing, and editing needs within it. Needs have two or more properties. Managers cannot interact with the 1 funding basket each user has. 
 
 ## Architecture and Design
@@ -278,13 +280,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.
+  - Low Coupling is present in our design when viewing the ViewModel tier, as controllers only talk to their own services as well as `AuthService`. Services have minimal interactions with other services and their own DAO's, demonstrating that our architecture is present in our implementation. No class has that bad of coupling, with `AuthService` having the most but it could be changed to only interact with controllers.
 - 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.
+  - For example, this principle is showcased in our `AuthService`. Instead of having services handle authorization, we have split the authorization part into a new AuthService class to handle login and authorization, while the other services handle just the CRUD operations pertaining to the their respestive function. 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.
+  - This principle is present in our controllers, as they only handle communication between the front and back end, letting the services deal with logic and error handling. For example, in `CupboardController`, it's methods only deal with handling back end calls for needs and passing the calls to the services, where they check for faulty values and other issues with need creation, editing, etc.
 
 > _**[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._
 
diff --git a/ufund-api/src/main/java/com/ufund/api/ufundapi/persistence/CupboardFileDAO.java b/ufund-api/src/main/java/com/ufund/api/ufundapi/persistence/CupboardFileDAO.java
index 7efda83..b3a176b 100644
--- a/ufund-api/src/main/java/com/ufund/api/ufundapi/persistence/CupboardFileDAO.java
+++ b/ufund-api/src/main/java/com/ufund/api/ufundapi/persistence/CupboardFileDAO.java
@@ -16,7 +16,7 @@ public class CupboardFileDAO implements CupboardDAO {
 
     private final Map<Integer, Need> needs; // cache
     private final ObjectMapper objectMapper;
-    private static int nextId;
+    private int nextId;
     private final String filename;
 
     public CupboardFileDAO(@Value("${cupboard.file}") String filename, ObjectMapper objectMapper) throws IOException {
@@ -26,7 +26,7 @@ public class CupboardFileDAO implements CupboardDAO {
         load();
     }
 
-    private synchronized static int nextId() {
+    private synchronized int nextId() {
         int id = nextId;
         nextId++;
         return id;