L'esclusione dei metodi concreti ha un odore di codice?

È vero che ignorare metodi concreti è un odore di codice? Perché penso che se hai bisogno di scavalcare metodi concreti:

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

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

può essere riscritto come

public interface A{
    public void a();
}

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

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

e se B vuole riutilizzare a () in A, può essere riscritto come:

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

che non richiede l'ereditarietà per sovrascrivere il metodo, è vero?

No, non è un odore di codice.

• Se una classe non è definitiva, consente di essere sottoclassata.
• Se un metodo non è definitivo, consente di ignorarlo.

Spetta alle responsabilità di ogni classe considerare attentamente se la sottoclasse è appropriata e quali metodi possono essere ignorati .

La classe può definire se stessa o qualsiasi metodo come definitivo, oppure può imporre restrizioni (modificatori di visibilità, costruttori disponibili) su come e dove viene sottoclassata.

Il solito caso di metodi di sostituzione è un'implementazione predefinita nella classe base che può essere personalizzata o ottimizzata nella sottoclasse (specialmente in Java 8 con l'avvento dei metodi predefiniti nelle interfacce).

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

Un'alternativa per superiori comportamento è il modello di strategia , in cui il comportamento è astratto come interfaccia, e l'implementazione può essere impostato nella classe.

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

È vero che ignorare metodi concreti è un odore di codice?

Sì, in generale, l'override di metodi concreti è un odore di codice.

Poiché il metodo di base ha un comportamento ad esso associato che gli sviluppatori di solito rispettano, la modifica che porta a bug quando l'implementazione fa qualcosa di diverso. Peggio ancora, se cambiano il comportamento, l'implementazione precedentemente corretta potrebbe aggravare il problema. E in generale, è abbastanza difficile rispettare il principio di sostituzione di Liskov per metodi concreti non banali.

Ora, ci sono casi in cui questo può essere fatto ed è buono. I metodi semi-banali possono essere superati in modo abbastanza sicuro. Metodi di base che esistono solo come un "default sano" tipo di comportamento che è destinata ad essere sovrascritta hanno alcuni usi buoni.

Quindi, questo mi sembra un odore - a volte buono, di solito cattivo, date un'occhiata per essere sicuro.

se è necessario sostituire metodi [...] concreti, è possibile riscriverlo come

Se può essere riscritto in questo modo, significa che hai il controllo su entrambe le classi. Ma poi sai se hai progettato la classe A per essere derivata in questo modo e se lo hai fatto, non è un odore di codice.

Se, d'altra parte, non hai il controllo sulla classe base, non puoi riscrivere in quel modo. Quindi o la classe è stata progettata per essere derivata in questo modo, nel qual caso basta andare avanti, non è un odore di codice, oppure no, nel qual caso hai due opzioni: cercare un'altra soluzione del tutto o andare avanti comunque , perché il lavoro ha la meglio sulla purezza.

Innanzi tutto, vorrei sottolineare che questa domanda è applicabile solo in alcuni sistemi di battitura. Ad esempio, in digitazione strutturali e di battitura anatra sistemi - una classe semplicemente avere un metodo con lo stesso nome e firma avrebbe significherebbe che classe era tipo compatibile (almeno per quel particolare metodo, nel caso di battitura Duck).

Questo è (ovviamente) molto diverso dal regno dei linguaggi tipicamente statici , come Java, C ++, ecc. Così come la natura della tipizzazione Strong , usata sia in Java e C ++, sia in C # e altri.

Immagino che tu provenga da un background Java, in cui i metodi devono essere esplicitamente contrassegnati come finali se il progettista del contratto intende che non vengano ignorati. Tuttavia, in lingue come C #, è l'opposto il valore predefinito. I metodi sono (senza alcuna decorazione, parole chiave speciali) " sigillate " (C # 's versione di final), e devono essere dichiarati esplicitamente come virtualse essi sono autorizzati ad essere sovrascritta.

Se un'API o una libreria è stata progettata in questi linguaggi con un metodo concreto che è sovrascrivibile, deve (almeno in alcuni casi) avere senso che venga sovrascritto. Pertanto, non è un odore di codice ignorare un finalmetodo non sigillato / virtuale / non concreto.     _{(Ciò presuppone ovviamente che i progettisti dell'API stiano seguendo le convenzioni e contrassegnando come virtual(C #) o contrassegnando come final(Java) i metodi appropriati per ciò che stanno progettando.)}

Guarda anche

• Sistema di tipo strutturale
• Duck typing
• Digitazione statica
• Digitazione forte
• Principio di sostituzione di Liskov

Sì, è perché può portare a chiamare super -pattern. Può anche denaturare lo scopo iniziale del metodo, introdurre effetti collaterali (=> bug) e far fallire i test. Utilizzeresti una classe le cui unit test sono rosse (failling)? Non lo farò.

Vado ancora oltre dicendo che l'odore iniziale del codice è quando un metodo non è abstractné final. Perché permette di alterare (sovrascrivendo) il comportamento di un'entità costruita (questo comportamento può essere perso o alterato). Con abstracte finall'intento non è ambiguo:

• Riassunto: è necessario fornire un comportamento
• Finale: si sta non autorizzato a modificare il comportamento

Il modo più sicuro per aggiungere un comportamento a una classe esistente è quello che mostra il tuo ultimo esempio: usare il motivo decorativo.

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