From d9862b85c0240b520e5c473368173c021f96315f Mon Sep 17 00:00:00 2001 From: "mael.daim" Date: Tue, 16 Jan 2024 09:54:21 +0100 Subject: [PATCH] applied required review's changement --- Documentation/Description.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/Documentation/Description.md b/Documentation/Description.md index ddb7dd0..fee90c5 100644 --- a/Documentation/Description.md +++ b/Documentation/Description.md @@ -21,7 +21,7 @@ Such as assets having all the image and stuff, model containing all the data's s Finally, we have the package "Api" that allows to share code and bind all the different third-hand application such as the web admin one. -## Main class diagram. +## Main data class diagram. ![Class diagram](./assets/models.svg) You can see how our data is structured contained in the package "data" as explained right above. @@ -33,7 +33,7 @@ We had to do it this way because of the language PHP that doesn't implement such Now, let's discuss a much bigger part of the diagram. In this part we find all the team logic. Actually, a team only have an array of members and a "TeamInfo". -The class "TeamInfo" exist to allows to split the data of the members. +The class "TeamInfo" only exists to split the team's information data (name, id etc) from the members. The type Team does only link the information about a team and its members. Talking about them, their class indicate what role they have (either Coach or Player) in the team. Because a member is registered in the app, therefore he is a user of it. Represented by the type of the same name. @@ -42,14 +42,14 @@ The last class we have is the Account. It could directly be incorporated in User Then, Account only has a user and a token which is an identifier. ## Validation's class diagram -![validation's class diagram](./assets/Validation.svg) +![validation's class diagram](./assets/validation.svg) We implemented our own validation system, here it is! For the validation methods (for instance those in DefaultValidators) we use lambda to instantiate a Validator. In general, we use the implementation "SimpleFunctionValidator". We reconize the strategy pattern. Indeed, we need a family of algorithms because we have many classes that only differ by the way they validate. -Futhermore, you may have notices the ComposedValidator that allows to chain several Validator. -We naturally used the composite pattern to solve this problem. +Futhermore, you may have notices the ComposedValidator that allows to chain several Validator. +We can see that this system uses the composite pattern The other part of the diagram is about the failure a specific field's validation. We have a concrete class to return a something more general. All the successors are just more precise about the failure. @@ -63,8 +63,7 @@ Finally, we have the JsonHttpResponse that renders, as it's name says, some Json ## Session's class diagram ![Session's class diagram](./assets/session.svg) -It encapsulates the PHP's array "$_SESSION" and kind of replaces it. With two interfaces that dictate how a session should be handled, and same for a mutable one. - +It encapsulates the PHP's array "$_SESSION". With two interfaces that dictate how a session should be handled, and same for a mutable one. ## Model View Controller All class diagram, separated by their range of action, of the imposed MVC architecture. All of them have a controller that validates entries with the validation system and check the permission the user has,and whether or not actually do the action.