Design Patterns - SENG-350-2024-fall/Team-8 GitHub Wiki
Design Patterns
Singleton Class
Ensures a class has only one instance and provides a global access point to it. It is useful for centralized management of resources or configurations.
- Manifestation in System: To interface with the databases, we have created APIs (called clients) that allow an easy way to do database calls. However, there should only ever be a single client to interface with its respective database. So, we used the singleton class to centralize the way database calls are done; through a single, global API for each database.
State Machine
Manages an object’s behaviour based on its current state. It allows the object to change behaviour dynamically as its state changes.
- Manifestation in System: This design pattern was used in the Ticket objects. A support ticket, generated by a user, is sent to the Admins. The ticket can be in two states, open and complete. When a ticket is open, the Admin can update the ticket and add comments to the ticket. However, when the ticket is complete, the Admin cannot change anything in the ticket, but can only view the ticket details. The EMT objects also carry with them one of two availability states. When an EMT is logged in they enter the available state, and will be able to receive dispatch requests. When they are logged out or out on a dispatch, they enter the unavailable state and will be unable to receive dispatch requests until they enter the available state again.
Factory Method
Defines an interface for creating objects but lets sub-classes decide which class to instantiate, promoting flexibility in object creation.
- Manifestation in System: This design pattern was used in Account Creation and Login. Since many different types of users would use our system, each with their own sets of responsibilities/functionalities, a factory method was used to create the different types of users. It creates a User object of either Patient, Nurse, Doctor, EMT or Admin.
Decorator Pattern
Allows behaviour to be added to individual objects dynamically without affecting other objects of the same class, enhancing flexibility and modularity.
- Manifestation in System: This design pattern was used in Account Creation and Login. This is used in conjunction with the User Factory Method (explained above). Many user types will have their own sets of permissions to grant access to certain functionality. Therefore, a Decorator Pattern was designed to grant a user many different types of permissions. This provides flexibility since the permissions are not hard-coded with the user type. So if any changes or additions are required to the user types, even if a new user type were to be added, this design pattern will provide a flexible approach to granting permissions.
Chain of Responsibility
Passes a request along a chain of handlers until one handles it, enabling different parts of a system to handle requests independently and flexibly.
- Manifestation in System: This design pattern was used in Account Creation. In particular, this design pattern was used as a validation checker when creating an account. Since an account has many different constraints (certain fields are required to be filled in, passwords must be greater than 8 characters, etc.) it was easy to implement the Chain of Responsibility pattern for each constraint. The validation checker is performed prior to adding the user into the database. If a constraint isn't met, the associated validation checker will return an error, which gets displayed to the user so that they know what they need to do for the account creation to succeed.