> /System/Design/Design_Patterns

DESIGN PATTERNS

The Software Design Document (Deliverable 3) takes Intaliq’s client–server architecture down to class level with three Gang of Four patterns, applied mainly inside the backend where the business logic and external integrations live. Factory Method creates the right activity for each workout type, Observer keeps users and coaches informed about sessions, and Adapter connects the AI chatbox to an external AI service. Each one is described below with how it is applied, why it was chosen, and its class diagram.

Design Concerns

The SDD starts from the people who depend on the design — end users, coaches, the development team, testers and maintainers — and the concerns each design decision has to answer.

No.

Stakeholder

Concern to address

Addressed by

C-01

Development team, maintainers

Adding new activity types without changing existing code

Factory Method

C-02

End users, coaches

Receiving timely updates about sessions and booking decisions

Observer

C-03

Development team, product owners

Using external services without depending on one provider

Adapter

C-04

Testers

Testing each part of the system on its own

Client–server split, layered backend

C-05

End users

Keeping personal data secure

Client–server: all data access behind the server

Pattern Overview

ID

Pattern Name

Selected Design Patterns

NODE // DP-01

Factory Method

CLASSIFICATION: Creational

How It Is Applied

Users log three kinds of outdoor activity — running, hiking and cycling. Every log goes through the same steps: validate the data, calculate the calories burnt, and save it, but each activity validates and counts calories its own way. Instead of the main logging process deciding which object to build, each activity type has its own logger: when a user picks hiking, the HikingLogger creates a HikingActivity, and the logging process uses it without knowing its exact type.

Justification

A new activity, such as padel, only needs its own logger and activity class — the existing logging process does not change. Factory Method also makes the code easier to test and maintain, lets the same code work with existing and new activity classes, and lets several developers work on different activities at the same time.

Classes

ActivityLogger (abstract) defines logActivity(), createActivity() and saveActivity(). RunningLogger, HikingLogger and CyclingLogger override createActivity() to return a RunningActivity, HikingActivity or CyclingActivity, each implementing the Activity interface’s validate() and calculateCalories().

Expected Benefits

▹New activity types are added without editing the logging process.
▹Each activity keeps its own validation and calorie rules in one class.
▹Loggers and activities can be tested on their own.

Class Diagram

NODE // DP-02

Observer

CLASSIFICATION: Behavioural

How It Is Applied

The SessionService is the subject; the UserNotification and ReminderService classes are its observers. When something happens to a session — a group class is cancelled, for example — the subject notifies every observer, and each reacts independently: UserNotification alerts the user, and ReminderService updates the reminder schedule.

Justification

Several events must reach more than one party at once: a coach’s announcement goes to every admitted member, and in the “Book a Session” scenario the requesting user must learn whether the coach accepted or declined. If Session informed everyone directly, it would be tightly coupled to how messages are sent. With Observer it only announces that something changed — supporting usability, since users hear about every change to their sessions, and maintainability, since email or in-app observers can be added without touching Session.

Classes

SessionService implements the Subject interface (attach(), detach(), notifyObserver()), keeps a list of observers, and calls notifyObservers() from bookSession() and cancelSession(). UserNotification and ReminderService implement the Observer interface’s update().

Expected Benefits

▹Users and coaches are informed automatically when a session changes.
▹Session code stays focused on session data, not on message delivery.
▹New notification channels are added by registering another observer.

Class Diagram

NODE // DP-03

Adapter

CLASSIFICATION: Structural

How It Is Applied

A user types a fitness question and gets an answer from an external AI service — but that service expects requests and returns answers in its own format, not the one the backend uses. The ChatboxService only calls a standard AIChatService interface through sendMessage(). The AIServiceAdapter implements that interface: it converts the question into the external format, sends it over HTTPS, and converts the reply back before it reaches the app.

Justification

Provider-specific request and response handling stays out of the chatbox logic. If the external API changes, only the AIServiceAdapter changes; to switch to another AI provider, the team writes a new adapter that implements AIChatService, and ChatboxService barely changes.

Classes

ChatboxService holds an AIChatService and exposes askQuestion(). AIServiceAdapter implements sendMessage() and wraps the ExternalAIService, using convertRequest() and convertResponse() around its generateResponse().

Expected Benefits

▹The chatbox does not depend on any one AI provider.
▹External API changes are absorbed in a single class.
▹A new provider is supported by adding an adapter.