Risposta.

La delega delle responsabilità tramite composizione è una pratica di programmazione in cui un oggetto di una classe contiene un oggetto di un'altra classe (o classi) e li utilizza per implementare parte della propria logica, invece di ereditare il loro interfaccia.

Storia della questione

Le prime versioni della OOP si concentravano sull'ereditarietà, ma nel tempo la pratica ha dimostrato che la composizione offre spesso maggiore flessibilità, estensibilità e riduzione della coesione tra i componenti.

Problema

L'ereditarietà lega gli oggetti in modo rigido: le modifiche nella classe base influenzano tutti gli eredi, le gerarchie diventano complesse, si verifica una fragilità nell'architettura. La composizione elimina questi problemi permettendo di costruire sistemi più affidabili e manutenibili.

Soluzione

In C++, la delega viene implementata includendo l'oggetto di una classe come membro di un'altra classe. Nei metodi della classe wrapper vengono chiamati i metodi dell'oggetto incorporato.

Esempio di codice:

class Logger {
public:
    void log(const std::string& msg) {
        std::cout << msg << std::endl;
    }
};

class FileProcessor {
    Logger logger; // Composizione
public:
    void process(const std::string& filename) {
        logger.log("Elaborazione del file: " + filename);
        // ...
    }
};

Caratteristiche chiave:

• Coesione più debole, flessibilità
• Possibilità di cambiare l'oggetto delegato al volo
• Più facile da testare e mantenere

Domande trabocchetto.

La composizione può sostituire completamente l'ereditarietà?

No, l'ereditarietà è necessaria dove è richiesta la relazione "è" (is-a), la composizione è quando "ha" (has-a). Ad esempio, Button eredita da Widget, ma Car "ha" un Motore (composizione).

È possibile modificare il comportamento del metodo delegato nella composizione?

Sì, i metodi di delega possono essere adattati senza toccare la classe originale. Inoltre, è possibile cambiare dinamicamente l'oggetto delegato (ad esempio, tramite un puntatore o un puntatore unico).

La composizione è più lenta dell'ereditarietà?

No, nella maggior parte dei casi non c'è differenza nelle prestazioni. A volte l'ereditarietà aggiunge costi a causa delle chiamate virtuali (vtable), mentre la composizione dipende solo dalle dimensioni dell'oggetto.

Errori tipici e antipattern

• Utilizzo dell'ereditarietà dove è sufficiente la composizione
• Complesse composizioni di oggetti incapsulati senza necessità
• "Ingrossamento" delle classi con numerose dipendenze frammentate

Esempio dalla vita reale

Caso negativo

Nel progetto tutte le finestre di dialogo ereditavano dalla classe DialogWindow comune. L'aggiunta di una nuova logica aziendale portava a codice non funzionante in tutte le classi derivate.

Pro:

• Creazione rapida all'inizio
• Riutilizzo del codice

Contro:

• Struttura rigida
• Qualsiasi modifica influisce su tutto l'albero

Caso positivo

Le funzioni comuni sono state estratte in classi separate (logging, validazione), che vengono iniettate in ogni dialogo tramite composizione.

Pro:

• Flessibilità
• Facile sostituzione del comportamento

Contro:

• Richiede ulteriore progettazione
• Può portare a un'eccessiva dettagliatura