Report: Comparing Observer and Factory Design Patterns (Hiba Ammissa and Malak

Douida)

Introduction

In software development, design patterns provide proven solutions to common problems. Two
such patterns are the Observer pattern, which is behavioral, and the Factory pattern, which is
creational. This report compares these two design patterns, highlighting their definitions,
workings, appropriate use cases, and their pros and cons.

Comparison Table
Observer Pattern
→What is a behavioral design pattern?
Behavioral design patterns are a category of design patterns that focus on communication
between objects. They are concerned with algorithms and the assignment of responsibilities
between objects. These patterns help to manage complex control flows, encapsulate
algorithms, and distribute behaviors across classes, making the system more flexible and
easier to understand.

→ What is Observer Pattern?

The Observer pattern is a behavioral design pattern that defines a one-to-many dependency
between objects. When one object (the subject) changes state, all its dependent objects
(observers) are notified and updated automatically.

→How It Works
1. Subject: The subject maintains a list of observers and provides methods to attach or detach
observers.
2. Observers: Observers register themselves with the subject to receive updates. When the
subject's state changes, it notifies all registered observers by calling their update methods.

The Observer Design Pattern class diagram involves four main components: Subject,
Observer, ConcreteSubject, and ConcreteObserver. Here's an explanation of each component
and how they interact:
1. Subject: The subject maintains a list of observers and provides methods to attach and
detach observers.
-Responsibilities:
▪ Attach an observer.
▪ Detach an observer.
▪ Notify all observers of a state change.
2. Observer: The observer defines an updating interface for objects that should be notified of
changes in a subject.
- Responsibilities:
▪ Update itself based on changes in the subject.
3. ConcreteSubject: The concrete subject stores the state of interest to ConcreteObserver
objects and sends a notification to its observers when the state changes.
-Responsibilities:
▪ Implement methods to get and set state.
▪ Notify observers when the state changes.
4. ConcreteObserver: The concrete observer maintains a reference to a ConcreteSubject object
and implements the Observer updating interface to keep its state consistent with the subject's
state.
-Responsibilities:
▪ Update its state to reflect the state of the subject.

Implementation:
1. Observer Interface
- Defines the `update` method that observers must implement.
- Allows different observers to react to updates from the subject.

2. Subject Interface
- Defines methods to attach, detach, and notify observers.
- Manages the list of observers.

3. ConcreteSubject Class (WeatherStation)

- Implements the `Subject` interface and maintains a list of observers.
- Has methods to add and remove observers.
- Notifies all observers when the weather changes.
- Holds the current weather state and updates it with the `setWeather` method.

4. ConcreteObserver Classes (PhoneDisplay, TVDisplay)

- Implement the `Observer` interface.
- Maintain a reference to the current weather state.
- Update their state when notified by the subject.
- Display the updated weather state.

5. Usage Class (WeatherApp)

- Demonstrates the use of the Observer pattern.
- Creates instances of `WeatherStation`, `PhoneDisplay`, and `TVDisplay`.
- Attaches the observers to the `WeatherStation`.
 - Changes the weather, triggering notifications to all observers.

Workflow

1. Attach Observers: `PhoneDisplay` and `TVDisplay` are attached to `WeatherStation`.

2. State Change: The weather state in `WeatherStation` is updated using `setWeather`.
3. Notify Observers: `WeatherStation` calls `notifyObservers`, which invokes `update` on
each observer.
4. Update and Display: Each observer updates its state and displays the new weather.

Key Points

- Observer Pattern: Allows `WeatherStation` to notify multiple `Observer` objects about

weather changes.
- Loose Coupling: `WeatherStation` doesn't need to know the details of each observer, only
that they implement the `Observer` interface.
- Dynamic Subscription: Observers can be added or removed at runtime, allowing for flexible
updates.

This implementation ensures that any change in the weather is automatically communicated to
all registered observers, keeping the displays in sync with the current weather conditions.

→When to Use It

- When an abstraction has two aspects, one dependent on the other.

- When a change to one object requires changing others, and you don’t know how many
objects need to be changed.
- When an object should notify other objects without knowing who these objects are.

→ Pros

- Promotes loose coupling between the subject and its observers.

- Supports broadcast communication.
- Easy to add new observers dynamically without modifying the subject.

→Cons

- Can lead to memory leaks if observers are not correctly removed.

- Increased complexity with too many dependencies.

Factory Pattern

→What is a Creational Pattern?

Creational patterns deal with object creation mechanisms, trying to create objects in a manner
suitable to the situation. The basic form of object creation could result in design problems or
added complexity to the design. Creational design patterns solve this problem by controlling
the object creation process.

→What is Factory Pattern?

The Factory pattern is a creational design pattern that provides an interface for creating
objects in a superclass but allows subclasses to alter the type of objects that will be created.

→ How It Works
1. Factory Method: Defines an interface for creating an object but allows subclasses to alter
the type of objects that will be created.
2. Product: The product declares the interface, which is common to all objects that can be
produced by the creator and its subclasses.
3. Concrete Product: Concrete products are different implementations of the product interface.
4. Creator: The creator class declares the factory method that returns new product objects. It's
often an abstract class with a concrete method that calls the factory method.
In the image above:

Product Interface (Vehicle)

Vehicle: This is the interface or abstract class for products created by the factory method. It
defines a method printVehicle() which is implemented by all concrete products.
Concrete Products (FourWheeler, TwoWheeler)

FourWheeler: A concrete implementation of the Vehicle interface. It provides the actual

implementation of the printVehicle() method.
TwoWheeler: Another concrete implementation of the Vehicle interface, also providing its
own implementation of the printVehicle() method.
Creator Interface (VehicleFactory)

VehicleFactory: This is the interface or abstract class for creators. It declares the factory
method createVehicle() which returns an object of type Vehicle.
Concrete Creators (TwoWheelerFactory, FourWheelerFactory)
TwoWheelerFactory: A concrete implementation of the VehicleFactory interface. It
implements the createVehicle() method to return a TwoWheeler object.
FourWheelerFactory: Another concrete implementation of the VehicleFactory interface. It
implements the createVehicle() method to return a FourWheeler object.
How it Works:
The VehicleFactory declares the factory method createVehicle(), which is intended to return
an object of type Vehicle.
TwoWheelerFactory and FourWheelerFactory are concrete classes that implement the
VehicleFactory interface. Each of these concrete classes overrides the createVehicle() method
to return instances of TwoWheeler and FourWheeler, respectively.
Vehicle is the common interface for all products. Both FourWheeler and TwoWheeler classes
implement this interface and provide their own implementations of the printVehicle() method.

Implementation:
• Library Classes:

• Vehicle: Abstract class that declares an abstract method printVehicle(), defining

the common interface for all vehicles.
• TwoWheeler and FourWheeler: Concrete subclasses of Vehicle that implement
printVehicle() to specify behavior for two-wheeled and four-wheeled vehicles,
respectively.

• Factory Interface:

• VehicleFactory: Interface that declares the factory method createVehicle(). This

method is responsible for creating instances of Vehicle.

• Concrete Factories:

• TwoWheelerFactory and FourWheelerFactory: Classes that implement

VehicleFactory. They provide specific implementations of createVehicle() to
instantiate TwoWheeler and FourWheeler objects, respectively.

• Client Class:

• Client: A class that interacts with Vehicle objects through a VehicleFactory. It

initializes its pVehicle member using a factory passed into its constructor. This
approach allows the client code to work with Vehicle instances without needing to
know the concrete classes (TwoWheeler or FourWheeler) directly.

• Driver Program:

• GFG (Main Class): Demonstrates how the Factory Method pattern is used.
o It creates instances of TwoWheelerFactory and FourWheelerFactory.
o Uses these factories to create instances of TwoWheeler and FourWheeler
through the Client class.
o Calls printVehicle() on these instances to demonstrate their specific
behaviors.

→ When to Use It

- When a class cannot anticipate the class of objects it needs to create.

- When a class wants its subclasses to specify the objects to be created.
- To reduce the complexity and dependencies in your code by delegating the responsibility of
object instantiation to a separate class.

→Pros
- Promotes code reusability by providing a single place to instantiate objects.
- Supports the Open/Closed Principle by allowing new products to be created without
modifying existing code.
- Reduces code duplication by centralizing object creation.

→Cons

- Can lead to a more complex code structure with multiple subclasses.

- Not always straightforward to implement, especially with complex object creation processes.

Conclusion:

The Observer and Factory patterns serve different purposes in software design. The Observer
pattern is best suited for scenarios where multiple objects need to be kept in sync with a
subject, promoting loose coupling and dynamic observer management. On the other hand, the
Factory pattern excels in scenarios where object creation needs to be centralized and
customized by subclasses, promoting reusability and adherence to the Open/Closed Principle.
Understanding the strengths and weaknesses of each pattern allows developers to apply them
effectively, resulting in cleaner, more maintainable code.