Zmniejszenie płyty kotłowej w klasie, która implementuje interfejsy poprzez kompozycję

Mam klasę: Ajest to połączenie wielu mniejszych klas B, Ci D.

B, CI Dwdrożyć interfejsów IB, ICoraz IDodpowiednio.

Ponieważ Aobsługuje wszystkie funkcje B, Ci D, Anarzędzi IB, ICa IDtakże, ale to niestety prowadzi do wielu re-routing w realizacjiA

Tak jak:

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;}
    }
}

Czy istnieje sposób, aby pozbyć się przekierowania z płyty A? B, Ci Dwszystkie implementują różne, ale wspólne funkcje, i podoba mi się to Aimplementacja IB, ICa IDponieważ oznacza to, że mogę przekazać Asamą siebie jako zależność pasującą do tych interfejsów i nie muszę ujawniać wewnętrznych metod pomocniczych.

To, czego szukasz, jest powszechnie nazywane mixinami . Niestety C # natywnie nie obsługuje tych.

Istnieje kilka obejść: jeden , dwa , trzy i wiele innych.

Naprawdę podoba mi się ostatni. Pomysł użycia automatycznie generowanej klasy cząstkowej do wygenerowania płyty kotłowej jest prawdopodobnie najbliższy naprawdę dobremu rozwiązaniu:

[pMixins] to wtyczka Visual Studio, która skanuje rozwiązanie dla klas częściowych ozdobionych atrybutami pMixin. Oznaczając klasę jako częściową, [pMixins] może utworzyć plik za kodem i dodać dodatkowych członków do klasy

Chociaż nie redukuje to w samym kodzie, Visual Studio 2015 zawiera teraz opcję refaktoryzacji, aby automatycznie wygenerować dla ciebie płytkę.

Aby z tego skorzystać, najpierw utwórz interfejs IExamplei implementację Example. Następnie utwórz nową klasę Compositei wprowadź ją do dziedziczenia IExample, ale nie implementuj interfejsu.

Dodaj właściwość lub pole typu Exampledo swojej Compositeklasy, otwórz menu szybkich działań na tokenie IExamplew Compositepliku klasy i wybierz „Implementuj interfejs poprzez„ Przykład ”, gdzie„ Przykład ”w tym przypadku jest nazwą pola lub właściwości.

Należy pamiętać, że chociaż program Visual Studio wygeneruje i przekieruje wszystkie metody i właściwości zdefiniowane w interfejsie do tej klasy pomocniczej, nie przekieruje zdarzeń w momencie opublikowania tej odpowiedzi.

Twoja klasa robi za dużo, dlatego musisz zaimplementować tak wiele płyt grzewczych. W komentarzach mówisz:

bardziej sensowniej jest pisać Person.Walk () niż Person.WalkHelper.Walk ()

Nie zgadzam się. Chodzenie prawdopodobnie wiąże się z wieloma regułami i nie należy do Personklasy - należy do WalkingServiceklasy, w walk(IWalkable)której metoda implementuje Osoba IWalkable.

Podczas pisania kodu zawsze miej na uwadze SOLIDNE zasady. Dwa, które są tutaj najbardziej odpowiednie, to Separation of Concerns (wyodrębnij kod przejścia do osobnej klasy) i Segregacja interfejsu (podzielone interfejsy na określone zadania / funkcje / umiejętności). Wygląda na to, że możesz mieć część I z wieloma interfejsami, ale potem cofasz całą swoją dobrą pracę, wprowadzając je w jednej klasie.

To, czego szukasz, to wielokrotne dziedziczenie. Jednak ani C #, ani Java nie mają tego.

Możesz przedłużyć B od A. To wyeliminuje potrzebę prywatnego pola dla B, a także kleju przekierowującego. Ale możesz to zrobić tylko dla jednego z B, C lub D.

Teraz, jeśli możesz sprawić, że C odziedziczy po B, a D po C, to musisz mieć tylko A przedłużyć D ...;) - dla jasności, tak naprawdę nie zachęcam do tego w tym przykładzie, ponieważ nic nie wskazuje dla tego.

W C ++ możesz mieć A odziedziczone po B, C i D.

Ale wielokrotne dziedziczenie sprawia, że ​​programy są trudniejsze do uzasadnienia i ma swoje własne problemy; Ponadto często istnieje czysty sposób, aby tego uniknąć. Mimo to, czasami bez niego, konieczne jest dokonanie kompromisów projektowych między powtarzającym się szablonem a sposobem wyświetlania modelu obiektowego.

To trochę tak, jakbyś próbował połączyć kompozycję i dziedzictwo. Gdyby to był C ++, można użyć czystego rozwiązania dziedziczenia. Ale skoro tak nie jest, polecam przyjęcie kompozycji.