Ingegneria del Software - Mediator, Decorator, Bridge, Chain of Responsibility

Pubblicato:

Descrizione dei design pattern Mediator, Decorator, Bridge e Chain of Responsibility.

Mediator

Il Mediator è un design pattern comportamentale.

Definisce un oggetto che incapsula come un insieme di oggetti interagisce. Invece di rendere strettamente interconnessi tutti gli oggetti del gruppo, si può optare per eleggere un mediatore che si occupi di gestire le interazioni.

Problema e soluzione

  • Molti oggetti interagiscono con un gran numero di altri oggetti
  • Diventa difficile mantenere lasco il coupling fra gli oggetti
  • È più complicato nascondere l'utilizzo di certe classi all'esterno

  • Utilizzo di un oggetto con il compito di mediatore
  • Il mediator non avrà altro scopo che raccogliere le chiamate da altri oggetti e redirezionarle al destinatario atteso

UML

Loading diagram...

Codice mediator

public class Grid {
    private List<Appliance> appliances = new ArrayList<Appliance>();
    private Meter meter;
    public void setMeter(Meter meter) { this.meter = meter; }
    public void addAppliance(Appliance appliance) { appliances.add(appliance); }
    public void turnOnAll() { appliances.forEach(a -> a.turnOn()); }
    public void turnOffAll() { appliances.forEach(a -> a.turnOff()); }
    public void updateAll() {
        for(Appliance a : appliances) {
            int reading = a.update();
            meter.updateMeter(reading);
        }
    }
    public void turnOn(String appliance) {
        appliances.stream()
            .filter(a -> a.getName().equals(appliance))
            .forEach(a -> a.turnOn());
    }
    public void turnOff(String appliance) {
        appliances.stream()
            .filter(a -> a.getName().equals(appliance))
            .forEach(a -> a.turnOff());
    }
}

Codice colleagues: power

public class Meter {
    private Grid grid;
    private int reading = 0;
    Meter(Grid grid) { this.grid = grid; }
    public void turnOn() { grid.turnOnAll(); }
    public void turnOff() { grid.turnOffAll(); }
    public void updateMeter(int reading) {
        this.reading += reading;
    }
}

public class Switch {
    private Grid grid;
    Switch(Grid grid) { this.grid = grid; }
    public void turnOn() { grid.turnOn("Light"); }
    public void turnOff() { grid.turnOff("Light"); }
}

public class Button {
    private Grid grid;
    Button(Grid grid) { this.grid = grid; }
    public void turnOn() { grid.turnOn("Fan"); }
    public void turnOff() { grid.turnOff("Fan"); }
}

Codice colleagues: appliance

public abstract class Appliance {
    protected int consumption;
    protected boolean isOn = false;
    protected Meter meter;
    public void turnOn() { isOn = true; }
    public void turnOff() { isOn = false; }
    public int readConsumption() { return isOn ? consumption : 0; }
}

public class Light extends Appliance {
    Light() { this.consumption = 100; }
    public void makeLight() { /* ... */ }
}

public class Fridge extends Appliance {
    Fridge() { this.consumption = 200; }
    public void makeCold() { /* ... */ }
}

public class Fan extends Appliance {
    Fan() { this.consumption = 50; }
    public void makeAir() { /* ... */ }
}

Possibili applicazioni

  • Sistema UI con un controllo del flusso complesso
  • Accentramento della comunicazione in un sistema distribuito (es. coda di messaggi)
  • Gestione di una casa domotica

Pro e contro

  • Riduzione del coupling fra gli oggetti
  • Minore ripetizione di codice
  • Semplificazione delle relazioni fra gli oggetti

  • Rischio di creare un oggetto con troppi compiti
  • Il mediator potrebbe diventare un collo di bottiglia
  • Introduzione di una classe aggiuntiva potenzialmente superflua

Decorator

Il Decorator è un design pattern strutturale.

Permette di aggiungere funzionalità ad un oggetto dinamicamente, senza dover creare una sottoclasse.

Problema e soluzione

  • Si vogliono aggiungere delle funzionalità ad un oggetto specifico, non all'intera classe
  • Le funzionalità potrebbero variare a runtime
  • Evitare di dover gestire le ereditarietà multiple

  • Usare un oggetto che racchiuda quello originale, aggiungendo le funzionalità desiderate
  • Più decoratori possono essere aggiunti in cascata, ognuno dando il proprio contributo
  • Il decoratore è trasparente al client

UML

Loading diagram...

Codice: component

public interface IPizza {
    public void eat();
}

public class Pizza implements IPizza {
    @Override
    public void eat() { System.out.println("Una bella pizza"); }
}

Codice: decorators

public abstract class PizzaDecorator extends Pizza {
    protected IPizza pizza;
    public PizzaDecorator(IPizza pizza) { this.pizza = pizza; }
    @Override
    public void eat() { pizza.eat(); }
}

public class PizzaWithMozzarella extends PizzaDecorator {
    public PizzaWithMozzarella(IPizza pizza) { super(pizza); }
    @Override
    public void eat() {
        super.eat();
        System.out.println("con mozzarella");
    }
}

public class PizzaWithTomato extends PizzaDecorator {
    public PizzaWithTomato(IPizza pizza) { super(pizza); }
    @Override
    public void eat() {
        super.eat();
        System.out.println("con pomodoro");
    }
}

Possibili applicazioni

  • Estendere il codice di una libreria esterna
  • Creare un oggetto che vuole aggregare a piacimento caratteristiche diverse
  • Creare dei bot che si collegano al server in maniera diversa (es. polling, webhook)

Pro e contro

  • Aggiungere funzionalità a classi esistenti
  • Prendere caratteristiche da più classi senza utilizzare l'ereditarietà multipla
  • Creare delle feature riutilizzabili da più classi
  • Modificare le feature di un oggetto a runtime

  • Può diventare difficile rimuovere un singolo decorator una volta che si viene a formare una catena
  • Si potrebbero creare dipendenze impreviste legate all'ordine di inizializzazione dei decorator

Bridge

Il Bridge è un design pattern strutturale.

Permette di separare l'astrazione dall'implementazione, in modo che entrambe possano variare indipendentemente.

Problema e soluzione

  • Se un'astrazione può avere più implementazioni, il numero di classi da creare cresce esponenzialmente
  • Eventuali modifiche ad una classe andrebbero ripetute in tutte le altre
  • Si vuole poter espandere la classe in maniera ortogonale, con diverse combinazioni note di features

  • Separare astrazione e implementazione
  • Utilizzare la relazione di composizione invece che l'ereditarietà

UML

Loading diagram...

Codice: abstraction

public abstract class Shape {
    protected Drawing impl;
    public void setImplementor(Drawing imp) { this.impl = imp; }
    public void drawLine(int x, int y, int z, int t){ impl.drawLine(x, y, z, t);}
    public abstract void draw();
}

public class Rectangle extends Shape {
    int x1, y1, x2, y2;
    public Rectangle(int x1, int y1, int x2, int y2) {
        this.x1 = x1;
        this.y1 = y1;
        this.x2 = x2;
        this.y2 = y2;
    }
    @Override
    public void draw() {
        drawLine(x1, y1, x1, y2); drawLine(x1, y1, x2, y1);
        drawLine(x1, y2, x2, y2); drawLine(x2, y1, x2, y2);
    }
}

Codice: implementor

public interface Drawing {
    public void drawLine(int x1, int y1, int x2, int y2);
}

public class RedDrawing implements Drawing {
    @Override
    public void drawLine(int x1, int y1, int x2, int y2) {
        System.out.println("Disegno una linea rossa da (x1, y1) a (x2, y2)");
    }
}

public class BlueDrawing implements Drawing {
    @Override
    public void drawLine(int x1, int y1, int x2, int y2) {
        System.out.println("Disegno una linea blu da (x1, y1) a (x2, y2)");
    }
}

Possibili applicazioni

  • Tipi diversi di astrazioni ed implementazioni di cui bisogna considerare tutte le possibili combinazioni
  • Tipi diversi di figure e modi per disegnarle
  • Modelli di macchine con tipologie di motori differenti

Pro e contro

  • Maggiore separazione fra le classi con scopi diversi
  • Il client tende a lavorare solo con le astrazioni ad alto livello, ignaro delle implementazioni
  • Si tende a seguire il principio della singola responsabilità

  • Potrebbe essere complicato da applicare a classi estremamente interdipendenti
  • Aggiunge un livello di astrazione in più che potrebbe non essere necessario

Chain of responsibility

La Chain of Responsibility è un design pattern comportamentale.

Permette di creare una catena di oggetti che si occupano di gestire una richiesta, passandola in avanti se non sono in grado di gestirla.

Problema e soluzione

  • È necessario applicare una serie di operazioni in sequenza
  • L'ordine delle operazioni potrebbe variare a seconda di parametri noti a runtime
  • Si vuole evitare di dover verificare una serie di condizioni legate da una relazione di congiunzione

  • Creare una serie di oggetti, ognuno specializzato in una determinata operazione
  • Passare la richiesta da un oggetto al prossimo nella catena
  • Se l'operazione non va a buon fine, la richiesta viene passata al prossimo oggetto

UML

Loading diagram...

Codice: interfacce e classi astratte

public Interface Validation {
    public void handleRequest(Request request);
}

public abstract class EmailValidation implements Validation {
    private EmailValidation successor;
    public void setSuccessor(EmailValidation successor) { 
        this.successor = successor; 
    }
    public void handleRequest(Request request) {
        if (successor)
            successor.handleRequest(request);
        else
            System.out.println("Email validata!");
    }
}

Codice: concrete handler

public class EmailValidationAt extends EmailValidation {
    public void handleRequest(Request request) {
        if(request.getData().contains("@")) {
            super.handleRequest(request);
        } else {
            System.out.println("Email non valida");
        }
    }
}

public class EmailValidationDomain extends EmailValidation {
    public void handleRequest(Request request) {
        if(request.getData().contains(".")) {
            super.handleRequest(request);
        } else {
            System.out.println("Email non valida");
        }
    }
}

Possibili applicazioni

  • Sistema di autenticazione
  • Gestione della validazione dell'input
  • Supporto agli utenti

Pro e contro

  • Si può controllare la gestione delle richieste secondo uno schema lineare
  • Ogni classe si occupa di gestire un caso specifico

  • Bisogna aggiungere un handler per ogni possibile caso, il che potrebbe portare ad una catena molto lunga
  • Non c'è garanzia che la richiesta venga gestita

Challenge

  • (Mediator) Creare un sistema di gestione di un'abitazione domotica. Il mediator potrebbe essere Alexa o Google Home
  • (Decorator) Creare un sistema di negozio che vende biglietti regalo. Questi possono avere un packaging e decorazioni diverse
  • (Bridge) Creare un sistema di gestione di un'azienda che produce macchine. Le macchine possono avere motori diversi
  • (Chain of responsibility) Creare un sistema di autenticazione