Week 12

Recap: What exactly is a Design Pattern?

Recap: The Three GoF Categories

The Gang of Four (GoF) grouped 23 famous patterns into three families. This family tells you what kind of problem the pattern solves.

Recap: Factory Method

Problem it solves

• You need to create objects, but the exact type changes at runtime
• You want to avoid long if-else or switch chains
• You want to add new types without touching stable client logic

One creator hierarchy decides which product object to create

Recap: Abstract Factory

One factory creates a matching chair + table family

What is different from Factory Method?

• Factory Method: usually one product at a time
• Abstract Factory: multiple related products together
• Best when consistency matters, like theme families, platform families, or regional product sets

Recap: Builder Pattern

Problem it solves

• Objects have many optional parameters
• Constructors become huge and confusing
• Callers start passing lots of null values or parameters in the wrong order

Builder stores construction steps and returns the final product only at the end

Recap: Prototype Pattern

The client clones a prototype instead of constructing another full object

Best when

• Object creation is expensive
• You need many similar objects with small differences
• You want a quick way to duplicate a known state

Example: clone a red circle, then change only the color to blue.

Recap: Singleton Pattern

Good candidates

• Logger
• Configuration manager
• Application-wide shared service

Important: use it carefully because global state can make testing difficult.

Clients do not create new objects directly; they all use the same shared instance

The Crux: Creational Patterns at a Glance

What are Structural Design Patterns?

What problem do they solve?

• Real systems are built from many classes, not just one
• Existing classes often do not fit together — different interfaces, different vendors
• We want to add features without rewriting stable old code
• We want one simple interface over a complicated subsystem
• We need tree-like hierarchies where parts and wholes behave the same

The 7 GoF structural patterns — we cover the 4 highlighted this week

Why Structural Patterns Matter

Now that we know how to create objects from Week 11, the next question is: how do we organize and connect those objects? That is exactly where structural patterns help.

Introduction to the Adapter Pattern

🔌 The international travel plug

You land in London with your Pakistani/US charger. The wall has a UK socket. Your charger works perfectly — it is not broken. The socket works perfectly — it is not broken. They just do not match.

You buy a travel adapter from the airport shop. It does not change your charger. It does not change the wall. It sits in between and translates one shape into another.

In software terms

• Old code and new code expose different method names
• Third-party libraries may not match your system's interface
• You want reuse without rewriting stable existing classes
• You are integrating a legacy system into a modern app

The adapter sits between incompatible interfaces without changing either side

Core Components of the Adapter Pattern

How the Adapter Works

Adapter Pattern: UML Class Diagram

The formal UML diagram shows how the four participants connect. Study each arrow carefully.

Adapter implements Target and delegates to Adaptee internally

UML → Plug example mapping

UML Role	Plug Example
Target	USPlug interface
Adapter	PlugAdapter class
Adaptee	EuropeanPlug class
Client	Main class

Key UML arrows

• Dashed arrow (implements): Adapter implements Target interface
• Diamond arrow (composition): Adapter holds a reference to Adaptee
• Simple arrow (uses): Client depends on Target only

Code example: Adaptee and Target Interface

First we define the old class that already exists, and the new interface that the client expects.

public class EuropeanPlug {
    public void connectEuropeanSocket() {
        System.out.println("European plug connected.");
    }
}

public interface USPlug {
    void connectUSSocket();
}

Code example: The Adapter Class

The adapter implements the target interface and internally holds the adaptee object.

public class PlugAdapter implements USPlug {
    private EuropeanPlug europeanPlug;

    public PlugAdapter(EuropeanPlug europeanPlug) {
        this.europeanPlug = europeanPlug;
    }

    @Override
    public void connectUSSocket() {
        System.out.println("Adapter converts U.S. socket request...");
        europeanPlug.connectEuropeanSocket();
    }
}

Complete Code example

public class Main {
    public static void main(String[] args) {
        EuropeanPlug europeanPlug = new EuropeanPlug();
        USPlug adapter = new PlugAdapter(europeanPlug);

        adapter.connectUSSocket();
    }
}

Adapter Pattern: Applicability, Pros & Cons

Additional Example: Adapter Pattern

Introduction to the Bridge Pattern

🎮 Remote control analogy

Think of a TV remote control. The remote (abstraction) has buttons like power, volume up, channel change. The device it controls (implementation) can be a TV, a Radio, or a Smart Speaker.

A basic remote has simple buttons. An advanced remote adds mute and favorites. Both remote types can work with any device. The remote and the device evolve independently.

The problem it solves

• Without Bridge, you would need: BasicTV, BasicRadio, AdvancedTV, AdvancedRadio… — a class explosion
• Adding one new remote type means creating N new classes (one per device)
• Adding one new device means creating M new classes (one per remote)
• Bridge reduces M×N classes to just M + N

Any remote can control any device — they are connected by a bridge, not by inheritance

Core Components of the Bridge Pattern

Bridge Pattern: UML Class Diagram

Two parallel hierarchies connected by composition, not inheritance

Key insight from the UML

• The left side (Abstraction) defines what operations exist
• The right side (Implementor) defines how those operations work
• The diamond arrow (composition) is the bridge itself
• Both sides can grow independently without affecting each other

Adapter vs Bridge — important difference

Adapter is applied after the design — to fix an incompatibility. Bridge is designed from the start — to prevent class explosion and keep hierarchies separate.

Code example: Implementor and Concrete Implementors

First, we define the implementation interface and two concrete devices.

public interface Device {
    void turnOn();
    void turnOff();
    void setVolume(int volume);
}

public class TV implements Device {
    @Override
    public void turnOn() {
        System.out.println("TV is ON");
    }
    @Override
    public void turnOff() {
        System.out.println("TV is OFF");
    }
    @Override
    public void setVolume(int volume) {
        System.out.println("TV volume: " + volume);
    }
}

public class Radio implements Device {
    @Override
    public void turnOn() {
        System.out.println("Radio is ON");
    }
    @Override
    public void turnOff() {
        System.out.println("Radio is OFF");
    }
    @Override
    public void setVolume(int volume) {
        System.out.println("Radio volume: " + volume);
    }
}

Code example: Abstraction, Refined Abstraction & Client

public class RemoteControl {
    protected Device device;    // ← The "bridge"

    public RemoteControl(Device device) {
        this.device = device;
    }

    public void togglePower() {
        device.turnOn();
    }

    public void volumeUp() {
        device.setVolume(10);
    }
}

public class AdvancedRemote extends RemoteControl {
    public AdvancedRemote(Device device) {
        super(device);
    }

    public void mute() {
        device.setVolume(0);
        System.out.println("Device is muted.");
    }
}

RemoteControl remote = new AdvancedRemote(new TV());
remote.togglePower();    // TV is ON
remote.volumeUp();       // TV volume: 10
((AdvancedRemote) remote).mute(); // TV volume: 0

Bridge Pattern: Applicability, Pros & Cons

Introduction to the Decorator Pattern

☕ Coffee shop analogy

You order a simple coffee (Rs. 500). Then you add milk (+Rs. 200). Then whipped cream (+Rs. 200). Each addition wraps the previous order and adds cost and description — but the original coffee object is never modified.

Each topping is a decorator: it adds behavior (extra cost, extra name) without changing the original component.

The subclassing problem

• Without Decorator: MilkCoffee, WhippedCreamCoffee, MilkWhippedCreamCoffee… — class explosion!
• Every combination needs its own class
• Decorator solves this by stacking wrappers at runtime

Each decorator wraps the previous one, adding behavior layer by layer

Core Components of the Decorator Pattern

Decorator Pattern: UML Class Diagram

The Decorator both implements and holds a Component — it IS-A and HAS-A Component

Key UML insight

• The Decorator class has a dual relationship with Component
• It implements Component (IS-A) — so the client sees the same interface
• It holds a Component (HAS-A) — so it can delegate and add behavior
• This recursive structure allows infinite stacking

Decorator vs Adapter — key difference

Adapter changes the interface of an object without adding behavior. Decorator keeps the same interface but adds new behavior. Both use wrapping, but for different purposes.

Code example: Component and Concrete Component

public interface Coffee {
    String getDescription();
    double getCost();
}

public class SimpleCoffee implements Coffee {
    @Override
    public String getDescription() {
        return "Simple Coffee";
    }

    @Override
    public double getCost() {
        return 500.0;
    }
}

Code example: Abstract Decorator and Concrete Decorators

public abstract class CoffeeDecorator implements Coffee {
    protected Coffee decoratedCoffee;   // ← wraps another Coffee

    public CoffeeDecorator(Coffee coffee) {
        this.decoratedCoffee = coffee;
    }
}

public class MilkDecorator
        extends CoffeeDecorator {

    public MilkDecorator(Coffee coffee) {
        super(coffee);
    }

    @Override
    public String getDescription() {
        return decoratedCoffee
            .getDescription() + ", Milk";
    }

    @Override
    public double getCost() {
        return decoratedCoffee
            .getCost() + 200.0;
    }
}

public class WhippedCreamDecorator
        extends CoffeeDecorator {

    public WhippedCreamDecorator(Coffee coffee) {
        super(coffee);
    }

    @Override
    public String getDescription() {
        return decoratedCoffee
            .getDescription()
            + ", Whipped Cream";
    }

    @Override
    public double getCost() {
        return decoratedCoffee
            .getCost() + 200.0;
    }
}

Code example: Client Code — Stacking Decorators

public class Main {
    public static void main(String[] args) {
        // Start with a simple coffee
        Coffee coffee = new SimpleCoffee();
        System.out.println(coffee.getDescription() + " → Rs. " + coffee.getCost());

        // Wrap with milk
        coffee = new MilkDecorator(coffee);
        System.out.println(coffee.getDescription() + " → Rs. " + coffee.getCost());

        // Wrap with whipped cream
        coffee = new WhippedCreamDecorator(coffee);
        System.out.println(coffee.getDescription() + " → Rs. " + coffee.getCost());
    }
}

Simple Coffee → Rs. 500.0
Simple Coffee, Milk → Rs. 700.0
Simple Coffee, Milk, Whipped Cream → Rs. 900.0

Decorator Pattern: Applicability, Pros & Cons

// Each wrapper adds a new capability — same pattern as our coffee example!
BufferedReader reader = new BufferedReader(      // adds buffering
    new InputStreamReader(                       // adapts bytes → chars
        new FileInputStream("data.txt")          // reads raw bytes
    )
);

Introduction to the Composite Pattern

Where this appears

• File systems: file and folder
• GUI frameworks: button and panel
• Organization charts: employee and team
• Menus: single item and submenu

Main question

Can I call the same operation on one object and on a whole group of objects? Composite says yes, if both follow the same component interface.

A folder can contain files or other folders, forming a tree structure

Understanding Composite with an Organization Tree

Director
├── Manager A
│   ├── Developer 1
│   └── Developer 2
├── Manager B
│   ├── Developer 3
│   └── Manager C
│       ├── Developer 4
│       └── Developer 5

Composite Pattern: UML Class Diagram

Composite both implements Component and holds a list of Components

The Key Elements

• Component: The shared interface for both simple and complex objects.
• Leaf: Individual objects that do the actual work. They have no children.
• Composite: Complex objects that hold children (Leaves or other Composites) and delegate work to them.

Why is it recursive?

Notice the line from Composite back to Component. Since a Composite holds a list of Components, and a Composite is a Component, it can hold other Composites inside itself indefinitely!

How Function Calls Propagate in Composite

Code example: Component and Leaf

We start with a common component interface, then create the leaf class for individual employees.

public interface Employee {
    void showDetails();
}

public class Developer implements Employee {
    private String name;
    private String position;

    public Developer(String name, String position) {
        this.name = name;
        this.position = position;
    }

    @Override
    public void showDetails() {
        System.out.println(name + " works as " + position + ".");
    }
}

Code example: Composite Node (Manager)

The composite also implements Employee, but instead of printing one line, it stores a list of child employees and delegates the call.

import java.util.ArrayList;
import java.util.List;

public class Manager implements Employee {
    private List<Employee> employees = new ArrayList<>();

    public void add(Employee employee) {
        employees.add(employee);
    }

    public void remove(Employee employee) {
        employees.remove(employee);
    }

    @Override
    public void showDetails() {
        for (Employee employee : employees) {
            employee.showDetails();
        }
    }
}

Complete Code example

public class Main {
    public static void main(String[] args) {
        Developer dev1 = new Developer("Ali", "Backend Developer");
        Developer dev2 = new Developer("Sara", "Frontend Developer");
        Developer dev3 = new Developer("Hamza", "Mobile Developer");

        Manager managerA = new Manager();
        managerA.add(dev1);
        managerA.add(dev2);

        Manager director = new Manager();
        director.add(managerA);
        director.add(dev3);

        director.showDetails();
    }
}

Composite Pattern: Applicability, Pros & Cons

Introduction to Behavioral Design Patterns

Why Behavioral Patterns Matter

Software systems are full of interactions: button clicks, menu actions, events, service calls, job queues, schedulers, and message passing. Behavioral patterns help make these interactions clear, flexible, and maintainable.

From Structural to Behavioral Thinking

Introduction to the Command Pattern

Command Pattern: Remote Control Analogy

The remote does not need device details; it just triggers a command

Mapping the analogy

• User gives the request
• Remote control is the invoker
• Command object wraps the action
• TV / Stereo / AC / Lights are receivers

Core Components of the Command Pattern

Command Pattern: Class Diagram

Invoker holds a command, commands talk to receivers

Reading the UML

• Command interface defines execute()
• Concrete commands connect one action to one receiver
• RemoteControl stores a command and calls it
• Device classes do the actual work

Code example: Command Interface and Concrete Commands

public interface Command {
    void execute();
}

class TurnOnCommand implements Command {
    private Device device;

    public TurnOnCommand(Device device) {
        this.device = device;
    }

    @Override
    public void execute() {
        device.turnOn();
    }
}

class TurnOffCommand implements Command {
    private Device device;

    public TurnOffCommand(Device device) {
        this.device = device;
    }

    @Override
    public void execute() {
        device.turnOff();
    }
}

Code example: Receivers and Invoker

interface Device {
    void turnOn();
    void turnOff();
}

class TV implements Device {
    public void turnOn() { System.out.println("TV is now on"); }
    public void turnOff() { System.out.println("TV is now off"); }
    public void changeChannel() { System.out.println("Channel changed"); }
}

class Stereo implements Device {
    public void turnOn() { System.out.println("Stereo is now on"); }
    public void turnOff() { System.out.println("Stereo is now off"); }
    public void adjustVolume() { System.out.println("Volume adjusted"); }
}

class RemoteControl {
    private Command command;

    public void setCommand(Command command) {
        this.command = command;
    }

    public void pressButton() {
        if (command != null) {
            command.execute();
        } else {
            System.out.println("No command assigned");
        }
    }
}

Complete Code example, Uses, Pros & Cons

public class Main {
    public static void main(String[] args) {
        TV tv = new TV();
        Stereo stereo = new Stereo();

        Command turnOnTV = new TurnOnCommand(tv);
        Command turnOffTV = new TurnOffCommand(tv);

        RemoteControl remote = new RemoteControl();

        remote.setCommand(turnOnTV);
        remote.pressButton();

        remote.setCommand(turnOffTV);
        remote.pressButton();
    }
}

Introduction to the Iterator Pattern

Why useful?

• The client should not care whether data is stored in an array, list, tree, or another structure
• Traversal logic is moved into a separate iterator object
• The collection can change internally without breaking client code

Pressing next on a remote abstracts the collection of channels

Core Components of the Iterator Pattern

The client interacts only with the Iterator and Aggregate interfaces

Key Parts

• Iterator Interface: Defines traversal (e.g. hasNext(), next()).
• Concrete Iterator: Implements traversal and keeps track of position.
• Aggregate: The collection providing a createIterator() method.
• Concrete Aggregate: The real list/tree holding the elements.

How Iterator Works: Employee Collection Example

Suppose a company stores employees in a collection, and we want to calculate the total salary by visiting each employee one by one.

Code example: Iterator and Aggregate Interfaces

We begin by defining two small interfaces: one for traversal and one for creating iterators.

interface Iterator<T> {
    boolean hasNext();
    T next();
}

interface Aggregate<T> {
    Iterator<T> createIterator();
}

Code example: Concrete Iterator and Company Aggregate

class EmployeeIterator implements Iterator<Employee> {
    private int currentIndex = 0;
    private List<Employee> employees;

    public EmployeeIterator(List<Employee> employees) {
        this.employees = employees;
    }

    @Override
    public boolean hasNext() {
        return currentIndex < employees.size();
    }

    @Override
    public Employee next() {
        if (!hasNext()) {
            throw new NoSuchElementException();
        }
        return employees.get(currentIndex++);
    }
}

class Company implements Aggregate<Employee> {
    private List<Employee> employees;

    public Company(List<Employee> employees) {
        this.employees = employees;
    }

    @Override
    public Iterator<Employee> createIterator() {
        return new EmployeeIterator(employees);
    }
}

Complete Code example

import java.util.ArrayList;
import java.util.List;
import java.util.NoSuchElementException;

class Employee {
    private String name;
    private double salary;

    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public double getSalary() {
        return salary;
    }
}

public class Main {
    public static void main(String[] args) {
        List<Employee> employees = new ArrayList<>();
        employees.add(new Employee("Alice", 50000));
        employees.add(new Employee("Bob", 60000));
        employees.add(new Employee("Charlie", 70000));

        Company company = new Company(employees);
        Iterator<Employee> iterator = company.createIterator();

        double totalSalary = 0;
        while (iterator.hasNext()) {
            totalSalary += iterator.next().getSalary();
        }

        System.out.println("Total salary: " + totalSalary);
    }
}

Iterator Pattern: Uses, Advantages & Disadvantages

Introduction to the Observer Pattern

How Observer Works

One subject, many observers, automatic notification on change

The flow

• Observers subscribe to the subject
• The subject stores a list of observers
• When state changes, the subject calls notifyObservers()
• Each observer reacts through its own update() method

Core Components of the Observer Pattern

Subject manages observers; concrete observers react to updates

Key parts

• Subject: add/remove observers, notify them
• Observer: common interface with update()
• ConcreteSubject: real data source, e.g. WeatherStation
• ConcreteObserver: real listeners, e.g. PhoneDisplay, TVDisplay

Code example: Subject and Observer Interfaces

public interface Subject {
    void addObserver(Observer observer);
    void removeObserver(Observer observer);
    void notifyObservers();
}

public interface Observer {
    void update(String weather);
}

Code example: Concrete Subject (WeatherStation)

import java.util.ArrayList;
import java.util.List;

class WeatherStation implements Subject {
    private List<Observer> observers = new ArrayList<>();
    private String weather = "";

    @Override
    public void addObserver(Observer observer) {
        observers.add(observer);
    }

    @Override
    public void removeObserver(Observer observer) {
        observers.remove(observer);
    }

    @Override
    public void notifyObservers() {
        for (Observer observer : observers) {
            observer.update(weather);
        }
    }

    public void setWeather(String newWeather) {
        this.weather = newWeather;
        notifyObservers();
    }
}

Code example: Concrete Observers and Usage

class PhoneDisplay implements Observer {
    @Override
    public void update(String weather) {
        System.out.println("Phone Display: Weather updated - " + weather);
    }
}

class TVDisplay implements Observer {
    @Override
    public void update(String weather) {
        System.out.println("TV Display: Weather updated - " + weather);
    }
}

public class WeatherApp {
    public static void main(String[] args) {
        WeatherStation weatherStation = new WeatherStation();

        Observer phoneDisplay = new PhoneDisplay();
        Observer tvDisplay = new TVDisplay();

        weatherStation.addObserver(phoneDisplay);
        weatherStation.addObserver(tvDisplay);

        weatherStation.setWeather("Sunny");
        weatherStation.setWeather("Rainy");
        weatherStation.setWeather("Cloudy");

        weatherStation.removeObserver(tvDisplay);
        weatherStation.setWeather("Windy");
    }
}

Observer Pattern: Uses, Advantages & Disadvantages

Week 11 Recap: Creational Patterns

Creational patterns answered one main question: How should objects be created? We studied five important patterns, each solving a different creation problem.

Week 12 Recap: Structural Patterns

Structural patterns answered the next question: Once objects exist, how should we connect them?

Behavioral Patterns Recap

Behavioral patterns focus on communication and responsibility. They answer: How should objects interact?

The Crux: All Patterns Studied So Far

Conclusion