Design Patterns - ISIS3510-MOBILE-T34/T34-Wiki-SpendiQ GitHub Wiki
Understanding that Design patterns are general, reusable solutions to common problems that occur in software design and they are like templates that can be applied to specific situations to solve design challenges effectively, the team decided to implement the following in the app's development:
1. Creational Design Pattern
The designed Singleton pattern ensures that only one instance of the critical component FirebaseConnection
exists throughout the application. This guarantees consistent access to shared resources, which can optimize the resources usage in the mobile application. This is very important taking into account the hardware limitations of mobile phones.
The Singleton pattern can be seen in the components diagram as a component that provides the connection between the Firebase Services Facade of the business layer and the Firestore methods:
2. Structural Design Pattern
The Facade architectural pattern was included inside the project's architecture to provide a set of simplified interfaces to manage our complex layers like the presentation and business layers, which contain many components.
Inside the architecture diagrams, it can be seen in the following cases:
- The
BusinessServicesFacade
abstracts the interactions between the multiple viewmodels and the services or models in the business layer. - The
FirebaseServicesFacade
abstracts the interactions between the multiple models, singleton and services components and the methods that manage data communication with the Firestore instance in the analytics engine. - The
ExternalServicesFacade
abstracts the interactions between the multiple models, services and the external services like the WhatsApp API. - The
LocalDatabaselServicesFacade
allows the communication between the models, services and the methods that communicate data with the local device's database.
The design of these facades can be seen in the Components Diagram.
3. Behavioral Design Pattern
The designed and implemented Observer pattern facilitates reactive updates between ViewModels and Views. When data changes in a ViewModel, subscribed Views automatically receive updates, ensuring the UI remains consistent with the underlying data without manual intervention.
This pattern can be seen in the components diagram, where each model is connected to the viewmodels' layer to send notification of state or data changes but not directly connected to a specific model.