Design Patterns - SENG-350-2024-fall/Team-11 GitHub Wiki

Template Method Design Pattern

Overview: The Template Method design pattern defines a general algorithm in a base class while allowing subclasses to customize specific parts of the algorithm. This ensures a consistent overall process while providing flexibility for customization.

Implementation in Our Design System: In our symptom evaluation system, the SymptomEvaluator class serves as the base class that outlines the steps for evaluating a patient's symptoms. The evaluate() method acts as the "template method" coordinating the evaluation process.

  1. Base Class:

    • The SymptomEvaluator class includes the evaluate() method, which guides how the evaluation should proceed. This method defines the sequence of steps involved in evaluating symptoms.

  2. Steps Defined:

    • The methods assessSeverity() and makeRecommendation() are defined in the SymptomEvaluator class, containing the logic for determining symptom severity and providing recommendations.

  3. Customization Example:

    • The SpecificSymptomEvaluator class is a subclass of SymptomEvaluator that overrides assessSeverity() to implement custom logic for evaluating specific symptoms. This allows for tailored evaluations while reusing the overall structure provided by the base class.

This is the most suitable design pattern for this page because using this design pattern, new types of evaluators can be easily added by creating subclasses that implement specific logic without rewriting the entire evaluation process.

Command Design Pattern

Overview: The command design pattern encapsulates a request as an object. It separates the object that invokes the operation from the one that knows how to perform it, promoting flexibility and decoupling of components.

Implementation in Our Design System: In the pharmacist system for submitting prescriptions, the command pattern is utilized to encapsulate actions related to prescription submissions.

  • Command Interface We define a command interface with an execute() method to standardize the way commands are executed.

  • Concrete Command The SubmitPrescriptionCommand class implements the command interface. This class takes care of preparing the prescription data and calling necessary methods to handle the submission process.

  • Invoker The invoker in this design is the submitPrescription() function, which triggers the command when the user submits the form. It creates a SubmitPrescriptionCommand instance and calls its execute() method, to decouple user interface from submission logic.

This design pattern is beneficial for the pharmacist system as it encapsulates prescription submission process, while maintaining a clear separation between the UI and the logic involved in handling submission. This results in a modular, maintainable code that can adapt to future requirements easily.

State Pattern

Overview: State Pattern allows an object to change itself (or, it's state) when a condition within itself changes. This change can be due to external input, or internal computation. It allows for clear "states" to exist, for easy understanding and relatively isolated behaviours.

Implementation in Our Design and System: Our log in and log out interface is done as so, with the entire website acting as a giant state machine. This is incomplete at the moment due to complications with the database. Some examples are shown below of what different states can look like or currently look like.

Examples in our design and system (not complete, but enough to give you an idea!): Each class of user (actor) will have different pages available to them, and certain pages (such as the home page) may display different information depending on who is logged in!

  • Logged out user view (home page, create account page, log in page, nothing else. everything else will redirect home or to log in page)
  • Logged in patient view (home page, enter symptoms page, prescription availability page, log out button but not log in page)
  • Logged in chemist/pharmacist view (home page, incoming prescriptions page, prescription details, etc. log out button)
  • Logged in doctor
  • Logged in nurse
  • Logged in system admin

Observer Design Pattern

Overview: The Observer pattern is a behavioral design pattern that establishes a one-to-many relationship between objects, allowing multiple dependent objects (observers) to be notified and updated automatically when the state of a subject changes.

Implementation in Our Design System: In the file ED_functions.js, I have implemented the Observer pattern through a class named ObserverImplementation. This class facilitates the management of observers by providing methods to add, remove, and notify observers whenever there is a change in the state of the subject.

  1. Subject:
  • In this design, the NewPatient class acts as the subject. It represents the incoming patient data that needs to be communicated to other components of the system.
  1. Observers: -The functions that need to be alerted when a new patient arrives are designated as observers. Currently, the incomingPatient function is the sole observer added to the NewPatient instance. However, the architecture allows for additional services to be incorporated into the observers' list as needed.

This setup ensures that any changes to the patient data are notified to all interested services, enhancing the system's responsiveness and maintaining a clear separation between the subject and its observers.

Adapter Design Pattern

Overview: The adapter design pattern allows the client to access methods from a class that they would not normally be able to interface with. It provides a translation service to take requests, and "translate" them into calls that a typically inaccessible class or application can understand.

Implementation in our design system: This design pattern is used frequently throughout the code as many different systems need to communicate with each other. As an example, this is used for communicating with our database stored in the AWS cloud. Typically, local machines are not able to connect to the database, and need to be on the Amazon Virtual Private Cloud network. At the current moment our system is using an SSH pipeline to redirect connections through this VPC to interact with the database. With this set up, the Node.js code that we are using, can connect directly to the database like it was a normal MongoDB database.