che deriva, classi decoratore derivate. Come? Suona come una buona idea o ci sono modi più adatti?

Ho la netta sensazione che il tuo "motivo decoratore" non corrisponda all'utilizzo convenzionale di quel termine.

Di solito, l'uso di questo modello implica una funzionalità extra nei metodi forniti dall'interfaccia , ad es. logging ("metodo X è stato chiamato con parametri Y e Z") o controllo dei limiti (il metodo su A si aspetta che param X sia compreso tra i valori Y e Z, decoratore lo verifica).

Tenendo presente questo, non è necessario un decorator base class - una classe decoratore implementa semplicemente l'interfaccia (inoltre, i decoratori di solito non pubblicano i propri metodi, poiché dovrebbero essere quasi sempre visti come un'istanza dell'applicazione interfaccia, nel tuo caso, di tipo I* o I& ).

Se ho capito bene il tuo problema, vuoi introdurre nuove funzionalità usando nuovi metodi (sui tuoi wrapper, dal momento che, per quanto posso dire, non sono decoratori), ma non so esattamente come fare tutti quelli aggiunti metodi visibili nell'oggetto risultante. In tal caso, suggerirei di utilizzare un approccio diverso: la composizione. (Puoi anche dare un'occhiata al modello di strategia .)

Esempio:

class A : public I {
    X* myX;
    Y* myY;
    Z* myZ;
public:
    A() { /* ... */ }
    void doSomething() { /* ... */ }

    X* getX() { return myX; }
    void setX(X* newX) {
        if(myX != nullptr) delete myX;
        myX = newX;
    }
    // repeat for Y and Z
};

// similar for Y and Z
class X {
public:
    // i left out constructor and stuff
    void doSomethingX() {
        // implement X specific methods
    }
};

Utilizzo:

void useSomethingofX(A* aObject) {
    if(aObject->getX() != nullptr) {
        // use X functionality
        aObject->getX()->doSomethingX();
    } else {
        // fallback or throw or ignore (X functionality not present
    }
}

void useSomethingOfXandYandZ(A* aObject) {
    if(aObject->getx() == nullptr || aObject->getY() == nullptr
        || aObject->getZ() == nullptr) return;

    aObject->getX()->doSomethingX();
    aObject->getY()->doSomethingY();
    aObject->getZ()->doSomethingZ();
}

Per quanto posso dire, questo probabilmente non è un problema ben noto. Ho giocato molto con le classi, le interfacce e i decoratori, eppure non ho mai incontrato un problema simile. Ciò che questo significa probabilmente è che ho evitato di mettermi nella posizione di avere un problema del genere, impiegando altre ben note best practice di refactoring e simlificazione sui miei progetti, quindi questo problema non ha mai avuto la possibilità di presentarsi.

Mi sembra che se devi fare cose così esotiche con i tuoi decoratori, forse la tua interfaccia originale "I" è troppo grande, troppo ricca. Non c'è vergogna nell'estrarre parte della funzionalità di "I" in un'interfaccia separata (ad esempio "J") e un metodo come J* getJ() in "I". In questo modo, le diverse preoccupazioni sono divise in diverse interfacce, ogni interfaccia ha i suoi decoratori e quindi la delega inizia a diventare una proposizione praticabile: quando viene richiamato getJ() , puoi ovviamente restituire this , ma puoi anche restituire myJmember che implementa J da solo, senza che nessuno debba derivarne.