Riduzione del boilerplate in classe che implementa le interfacce attraverso la composizione

Ho una classe: Aquesto è un composto di un numero di classi più piccole B, Ce D.

B, CE Dimplementare interfacce IB, ICe IDrispettivamente.

Dal momento che Asupporta tutte le funzionalità di B, Ce D, Aattrezzi IB, ICe IDcosì, ma questo purtroppo porta ad un sacco di ri-instradamento per l'attuazione delA

Così:

interface IB
{
    int Foo {get;}
}

public class B : IB
{
    public int Foo {get {return 5;}}
}

interface IC
{
    void Bar();
}

public class C : IC
{
    public void Bar()
    {
    }
}

interface ID
{
    string Bash{get; set;}
}

public class D: ID
{
    public string Bash {get;set;}
}

class A : IB, IC, ID
{
    private B b = new B();
    private C c = new C();
    private D d = new D();

    public int Foo {get {return b.Foo}}

    public A(string bash)
    {
        Bash = bash;
    }

    public void Bar()
    {
        c.Bar();
    }

    public string Bash
    {
         get {return d.Bash;}
         set {d.Bash = value;}
    }
}

C'è un modo per sbarazzarsi di uno qualsiasi di questo reindirizzamento del boilerplate A? B, CE Dtutto implementare funzionalità diverse ma comuni, e simili che Aimplementa IB, ICe IDperché significa posso passare in Asé come dipendenza corrispondenza tali interfacce, e non devono esporre i metodi di supporto interno.

Quello che stai cercando è comunemente chiamato mixins . Purtroppo, C # non supporta nativamente quelli.

Esistono alcune soluzioni alternative: una , due , tre e molte altre.

In realtà mi piace davvero l'ultimo. L'idea di utilizzare la classe parziale generata automaticamente per generare il boilerplate è probabilmente la più vicina possibile a una soluzione davvero valida:

[pMixins] è un plug-in di Visual Studio che esegue la scansione di una soluzione per classi parziali decorate con attributi pMixin. Contrassegnando la tua classe come parziale, [pMixins] può creare un file code-behind e aggiungere altri membri alla tua classe

Anche se non riduce la piastra di caldaia nel codice stesso, Visual Studio 2015 ora include un'opzione di refactoring per generare automaticamente la piastra di caldaia per te.

Per usarlo, crea prima l'interfaccia IExamplee l'implementazione Example. Quindi crea la tua nuova classe Compositee rendila ereditaria IExample, ma non implementare l'interfaccia.

Aggiungi una proprietà o un campo di tipo Examplealla tua Compositeclasse, apri il menu di azioni rapide sul token IExamplenel tuo Compositefile di classe e seleziona "Implementa l'interfaccia tramite" Esempio "" dove "Esempio" in questo caso è il nome del campo o della proprietà.

Si noti che mentre Visual Studio genererà e reindirizzerà tutti i metodi e le proprietà definiti nell'interfaccia su questa classe di supporto, non reindirizzerà gli eventi dal momento in cui questa risposta è stata pubblicata.

La tua classe sta facendo troppo, è per questo che devi implementare così tanto boilerplate. Dici nei commenti:

sembra più sensato scrivere Person.Walk () rispetto a Person.WalkHelper.Walk ()

Non sono d'accordo. L'atto di camminare probabilmente implica molte regole e non appartiene alla Personclasse - appartiene a una WalkingServiceclasse con un walk(IWalkable)metodo in cui la Persona implementa IWalkable.

Tieni sempre presente i principi SOLIDI quando scrivi il codice. I due che sono più applicabili qui sono Separazione delle preoccupazioni (estrai il codice ambulante in una classe separata) e Segregazione delle interfacce (suddivide le interfacce in compiti / funzioni / abilità specifici). Sembra che potresti avere un po 'dell'Io con le tue interfacce multiple, ma stai quindi annullando tutto il tuo buon lavoro facendo implementare una classe.

Quello che stai cercando è l'eredità multipla. Tuttavia, né C # né Java ce l'hanno.

Puoi estendere B da A. Questo eliminerà la necessità di un campo privato per B così come la colla di reindirizzamento. Ma puoi farlo solo per uno di B, C o D.

Ora, se riesci a far ereditare C da B, e D da C, devi solo avere A estendere D ...;) - solo per essere chiari, in realtà non lo sto incoraggiando in questo esempio poiché non ci sono indicazioni per questo.

In C ++ potresti avere A ereditato da B, C e D.

Ma l'ereditarietà multipla rende i programmi più difficili da ragionare e ha i suoi problemi; Inoltre, c'è spesso un modo pulito per evitarlo. Tuttavia, a volte senza di essa, è necessario effettuare compromessi di progettazione tra la ripetizione della piastra di caldaia e il modo in cui viene esposto il modello a oggetti.

È un po 'come se stessi provando a mescolare composizione ed eredità. Se fosse C ++, potresti usare una soluzione di eredità pura. Ma dato che non lo è, consiglierei di abbracciare la composizione.