具象メソッドのオーバーライドはコードの匂いですか？

具体的なメソッドをオーバーライドするのはコードの匂いだというのは本当ですか？なぜなら、具体的なメソッドをオーバーライドする必要があると思うからです：

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

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

次のように書き換えることができます

public interface A{
    public void a();
}

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

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

BがAでa（）を再利用したい場合、次のように書き換えることができます。

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

メソッドをオーバーライドするために継承を必要としないのは本当ですか？

いいえ、コードの匂いではありません。

• クラスが最終クラスでない場合、サブクラス化することができます。
• メソッドが最終的なものではない場合、オーバーライドできます。

サブクラス化が適切かどうか、およびどのメソッドがオーバーライドされる可能性があるかを慎重に検討することは、各クラスの責任内にあります。

クラスは、それ自体またはメソッドをfinalとして定義するか、サブクラス化の方法と場所に制限（可視性修飾子、利用可能なコンストラクター）を設定できます。

メソッドをオーバーライドする通常のケースは、サブクラスでカスタマイズまたは最適化できる基本クラスのデフォルト実装です（特にJava 8では、インターフェイスにデフォルトメソッドが出現します）。

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

動作をオーバーライドするための代替手段はStrategy Patternです。この場合、動作はインターフェースとして抽象化され、実装はクラスで設定できます。

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

具体的なメソッドをオーバーライドするのはコードの匂いだというのは本当ですか？

はい、一般的に、具体的なメソッドをオーバーライドすることはコードのにおいです。

基本メソッドには、開発者が通常尊重する振る舞いが関連付けられているため、実装を変更すると、変更するとバグが発生します。さらに悪いことに、それらが動作を変更する場合、以前の正しい実装は問題を悪化させる可能性があります。また、一般的に、非自明な具体的な方法については、リスコフの代替原則を尊重することはかなり困難です。

現在、これを行うことができ、良い場合があります。半自明なメソッドは、ある程度安全にオーバーライドできます。オーバーライドされることを意図した、「正常な」デフォルトの動作としてのみ存在する基本メソッドには、いくつかの優れた用途があります。

したがって、これは私には臭いのように見えます-時々良い、通常は悪い、確認するために見てください。

具体的なメソッドをオーバーライドする必要がある場合[...]

そのように書き換えることができる場合は、両方のクラスを制御できることを意味します。しかし、クラスAをこの方法で派生するように設計したかどうかはわかります。そのようにした場合、それはコードの匂いではありません。

一方、基本クラスを制御できない場合は、そのように書き換えることはできません。したがって、クラスはこの方法で派生するように設計されていますが、その場合は先に進むか、コードの匂いではないか、そうではありません。この場合、2つのオプションがあります。別のソリューションを探すか、とにかく先に進む作業はデザインの純度よりも重要だからです。

まず、この質問は特定のタイピングシステムでのみ適用可能であることを指摘しておきます。例えば、内構造タイピングとダックタイピングシステム-単にクラス有する同名＆と方法を署名はなる平均そのクラスであった互換性のある型（ダックタイピングの場合には、少なくともその特定のメソッドのために）。

これは（明らかに）Java、C ++などの静的に型付けされた言語の領域とは大きく異なります。また、JavaとC ++、およびC＃などの両方で使用される強い型付けの性質も異なります。

Javaのバックグラウンドから来ているのではないかと推測しています。コントラクトデザイナーがメソッドをオーバーライドしないように意図している場合、メソッドは明示的にfinalとしてマークする必要があります。ただし、C＃などの言語では、反対がデフォルトです。メソッドは（装飾や特別なキーワードなしで）「封印」（C＃のバージョン）であり、オーバーライドが許可されているかのように明示的に宣言する必要があります。finalvirtual

APIやライブラリは、具体的な方法でこれらの言語で設計されている場合で、それ必要があります（少なくともで、オーバーライドいくつかのそれが上書きされるためにケース（S））メイク感覚。したがって、unsealed / virtual / not finalconcreteメソッドをオーバーライドするのはコードの匂いではありません。     _{（これはもちろん、APIの設計者が慣例に従っており、virtual（C＃）としてマークfinalするか、設計しているものに適切なメソッドを（Java）としてマークしていることを前提としています。）}

こちらもご覧ください

• 構造型システム
• ダックタイピング
• 静的型付け
• 強い型付け
• リスコフ置換原理

はい、それはスーパーアンチパターンの呼び出しにつながる可能性があるためです。また、メソッドの最初の目的を悪化させ、副作用（=>バグ）を導入し、テストを失敗させる可能性があります。ユニットテストが赤（失敗）のクラスを使用しますか？しません。

最初のコードの匂いは、メソッドがそうでabstractないときfinalです。構築されたエンティティの動作を（オーバーライドすることにより）変更できるため（この動作は失われたり変更されたりする可能性があります）。abstractし、final意図は明確な次のとおりです。

• 要約：動作を提供する必要があります
• 最終：動作を変更することはできません

既存のクラスに動作を追加する最も安全な方法は、最後の例で示したものです：デコレータパターンを使用します。

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