Czy nadrzędne metody to zapach kodu?

Czy to prawda, że ​​nadrzędnymi konkretnymi metodami jest zapach kodu? Ponieważ uważam, że jeśli chcesz zastąpić konkretne metody:

public class A{
    public void a(){
    }
}

public class B extends A{
    @Override
    public void a(){
    }
}

można go przepisać jako

public interface A{
    public void a();
}

public class ConcreteA implements A{
    public void a();
}

public class B implements A{
    public void a(){
    }
}

a jeśli B chce ponownie użyć a () w A, można go przepisać jako:

public class B implements A{
    public ConcreteA concreteA;
    public void a(){
        concreteA.a();
    }
}

który nie wymaga dziedziczenia, aby zastąpić metodę, czy to prawda?

Nie, to nie jest zapach kodu.

• Jeśli klasa nie jest ostateczna, można ją zaklasyfikować do podklasy.
• Jeśli metoda nie jest ostateczna, można ją zastąpić.

Odpowiedzialność każdej klasy leży w starannym rozważeniu, czy podklasowanie jest właściwe i które metody można zastąpić .

Klasa może zdefiniować siebie lub dowolną metodę jako ostateczną, lub może nałożyć ograniczenia (modyfikatory widoczności, dostępne konstruktory) na sposób i miejsce jej podziału.

Zwykłym przypadkiem zastąpienia metod jest domyślna implementacja w klasie bazowej, którą można dostosować lub zoptymalizować w podklasie (szczególnie w Javie 8 wraz z pojawieniem się domyślnych metod w interfejsach).

class A {
    public String getDescription(Element e) {
        // return default description for element
    }
}

class B extends A {
    public String getDescription(Element e) {
        // return customized description for element
    }
}

Alternatywa dla nadrzędnym jest zachowanie wzoru Strategia , w której zachowanie jest wydobywane jako interfejs i implementacja może być ustawiony w klasie.

interface DescriptionProvider {
    String getDescription(Element e);
}

class A {
    private DescriptionProvider provider=new DefaultDescriptionProvider();

    public final String getDescription(Element e) {
       return provider.getDescription(e);
    }

    public final void setDescriptionProvider(@NotNull DescriptionProvider provider) {
        this.provider=provider;
    }
}

class B extends A {
    public B() {
        setDescriptionProvider(new CustomDescriptionProvider());
    }
}

Czy to prawda, że ​​nadrzędnymi konkretnymi metodami jest zapach kodu?

Tak, ogólnie rzecz biorąc, nadrzędnymi konkretnymi metodami jest zapach kodu.

Ponieważ metoda podstawowa jest powiązana z zachowaniem, które programiści zwykle szanują, zmiana ta będzie prowadzić do błędów, gdy twoja implementacja zrobi coś innego. Co gorsza, jeśli zmienią zachowanie, poprzednio poprawna implementacja może zaostrzyć problem. Ogólnie rzecz biorąc, dość trudne jest przestrzeganie zasady substytucji Liskowa w przypadku nietrywialnych konkretnych metod.

Teraz są przypadki, w których można to zrobić i jest to dobre. Półtrywialne metody można nieco bezpiecznie ominąć. Podstawowe metody, które istnieją tylko jako „rozsądne” zachowanie, które ma być nadrzędne, mają dobre zastosowanie.

Dlatego wydaje mi się to zapachem - czasem dobrze, zwykle źle, spójrz, aby się upewnić.

jeśli chcesz zastąpić konkretne metody [...], możesz je przepisać jako

Jeśli można go przepisać w ten sposób, oznacza to, że masz kontrolę nad obiema klasami. Ale wtedy wiesz, czy zaprojektowałeś w ten sposób klasę A, a jeśli tak, to nie jest to zapach kodu.

Jeśli z drugiej strony nie masz kontroli nad klasą podstawową, nie możesz przepisać w ten sposób. Więc albo klasa została zaprojektowana w taki sposób, aby wyprowadzić ją w ten sposób, w takim przypadku po prostu śmiało, nie jest to zapach kodu, albo nie było, w którym to przypadku masz dwie opcje: poszukaj innego rozwiązania w ogóle, lub idź naprzód , ponieważ atuty robocze projektują czystość.

Po pierwsze, chciałbym tylko zaznaczyć, że to pytanie ma zastosowanie tylko w niektórych systemach pisania. Na przykład, w typowania strukturalnych i kaczka wpisywanie systemów - klasa po prostu mając metodę o tej samej nazwie i podpis będzie oznaczać , że klasa była wpisać kompatybilny (przynajmniej dla tego konkretnego sposobu, w przypadku Duck wpisywanie).

Jest to (oczywiście) bardzo różne od dziedziny języków o typie statycznym , takich jak Java, C ++, itp. Jak również charakter silnego pisania , używanego zarówno w Javie i C ++, jak i C # i innych.

Domyślam idziesz z tła Java, gdzie metody muszą być wyraźnie oznaczone jako final jeśli projektant kontrakt zamierza dla nich nie do zmiany. Jednak w językach takich jak C # ustawienie domyślne jest odwrotne. Metody (bez dekoracji, szczególne słowa kluczowe), „ zamknięte ” (C # 's wersja final) i musi być jawnie zadeklarowane jako virtualjeśli są one dopuszczone do być pominięte.

Jeśli interfejs API lub biblioteka została zaprojektowana w tych językach przy użyciu konkretnej metody, którą można zastąpić, wówczas (przynajmniej w niektórych przypadkach) musi mieć sens zastąpienie tej metody . Dlatego nie jest to zapach kodu zastępujący niezamkniętą / wirtualną / nie finalkonkretną metodę.     _{(Zakłada się oczywiście, że projektanci API przestrzegają konwencji i albo oznaczają jako virtual(C #), albo oznaczają jako final(Java) odpowiednie metody do tego, co projektują.)}

Zobacz też

• System typów strukturalnych
• Pisanie kaczek
• Pisanie statyczne
• Mocne pisanie
• Zasada podstawienia Liskowa

Tak, ponieważ może to prowadzić do wywołania super -wzorca. Może również denaturować początkowy cel metody, wprowadzać skutki uboczne (=> błędy) i powodować niepowodzenia testów. Czy użyłbyś klasy, której testy jednostkowe są czerwone (wypełnianie)? Nie będę

Pójdę jeszcze dalej, mówiąc, że początkowy zapach kodu występuje, gdy metoda nie jest abstractani final. Ponieważ pozwala to zmienić (poprzez przesłonięcie) zachowanie skonstruowanej istoty (to zachowanie może zostać utracone lub zmienione). Z abstracti finalintencja jest jednoznaczna:

• Streszczenie: musisz zapewnić zachowanie
• Finał: jesteś nie wolno modyfikować zachowanie

Najbezpieczniejszym sposobem na dodanie zachowania do istniejącej klasy jest to, co pokazuje twój ostatni przykład: użycie wzoru dekoratora.

public interface A{
    void a();
}

public final class ConcreteA implements A{
    public void a() {
        ...
    }
}

public final class B implements A{
    private final ConcreteA concreteA;
    public void a(){
        //Additionnal behaviour
        concreteA.a();
    }
}