puoi farlo con il tuo esempio FeatureApi. hai bisogno di un paio di modifiche per esporre i campi protetti in A o B al FeatureApi avvolto

(sto per andare con c #)

class FeatureApi 
{
    FeatureApi(IExposeStuff parent) {..}

    public string myNewFeature()
    {
       var info = parent.GetProtectedInfo();
       //do stuff
    }
}

interface IExposeStuff
{
    string GetProtectedInfo();
}

class NewA : A, IExposeStuff
 {
    FeatureApi api;
    public NewA()
    {
        this.api = new FeatureApi(this)
    }

    public string GetProtectedInfo()
    {
        return this.protectedInfo;
    }
}

Sfortunatamente sei un po 'indeciso. Qualcun altro ti ha bloccato in una gerarchia ereditaria che non puoi cambiare. A seconda di come funzionano A e B , potresti essere costretto ad estendere ogni classe separatamente per implementare il tuo comportamento. Ecco alcuni scenari in base ai vincoli che affronti.

Devi eseguire l'override dei metodi da A e B .

In questo scenario A e B chiamano i propri metodi e la funzionalità che stai implementando richiede l'intercettazione di queste chiamate. Ad esempio:

class A {
    private void fizz() {
        buzz();
    }
    void buzz(); // <- you must override this to implement your functionality
}

In questo scenario il modo solo per ottenere il tuo comportamento su un'istanza raw di A è di estendere A e sovrascrivere buzz . Allo stesso modo, l'unico modo per ottenere il tuo comportamento su un'istanza di B è estendere B e sovrascrivere buzz . Devi estenderli separatamente ma potresti essere in grado di riutilizzare il codice facendo in modo che i due override di buzz chiamino un metodo di utilità statica o un metodo di istanza separato in A .

Questa situazione è scomoda perché sei bloccato a duplicare del codice e se dovessi implementare più funzionalità allo stesso modo, ora hai 4 classi da estendere. Se devi farlo ancora una volta hai 8 classi da estendere. Come puoi vedere, questo approccio non si adatta affatto bene.

Non è necessario eseguire l'override dei metodi da A e B .

In questo scenario, i metodi da A e B non richiedono "richiama" la nuova funzionalità. Questo scenario potrebbe consentire di utilizzare la delega tramite il pattern decoratore, a seconda di quanto sono tolleranti A e B . Questo approccio comporta l'estensione di A con una sottoclasse che accetta l'istanza "reale" di A e delega tutte le chiamate di metodo ad esso, implementando la tua funzionalità in aggiunta alle chiamate di metodo a A . Allo stesso modo estendere B per decorare B .

Il vantaggio piccolo che questo approccio ha rispetto al primo approccio è che dovresti essere in grado di implementare qualsiasi funzionalità aggiunta in termini di metodi di utilità che prendono l'istanza "reale" di A . Poiché B è un A , puoi chiamare questo metodo di utilità sia dal A decorator che dal B decorator.

Questo approccio potrebbe non essere fattibile se A ha solo costruttori che prendono dati specifici, poiché ogni sottoclasse dovrebbe chiamare i costruttori della superclasse. Potresti fondere i dati passati alla superclasse, ma farlo è hacky e fragile (cosa succede se A aggiunge una convalida che i dati danneggiati falliscono?).

Puoi introdurre le interfacce.

Se sei in grado di introdurre interfacce per A e B allora le tue opzioni si aprono notevolmente. In questo caso è possibile implementare il modello decoratore in modo pulito, senza preoccuparsi di chiamare un costruttore di una superclasse di cemento. Hai ancora bisogno di implementare due decoratori ma, poiché tutte le funzionalità che aggiungi possono essere implementate con metodi di utilità statici che accettano gli oggetti decorati, è necessario solo un duplicato standard.

Si noti che con questo approccio, non è necessario esporre le interfacce del decoratore. Il codice dipenderà solo da A e B . Pertanto, se devi aggiungere più funzionalità sia a A che a B , devi solo implementarlo due volte. Se è necessario aggiungere funzionalità una terza volta, è comunque necessario implementarlo due volte. Pertanto questo approccio si adatta molto meglio del primo.

Non utilizzare l'ereditarietà o le interfacce, sono entrambi inappropriati per la tua situazione. Dovresti invece usare il contenimento.

Crea un'istanza privata di classe A in una nuova classe MyA. Implementa le tue nuove cose. Ogni volta che hai bisogno di alcune funzionalità chiuse di A, chiama A. Puoi creare i tuoi nuovi metodi che hanno lo stesso nome dei metodi chiusi in A e solo delegati. Fai lo stesso con B.