抽象クラスを既に持っている場合、インターフェイスを定義するのは理にかなっていますか？

いくつかのデフォルト/共有機能を持つクラスがあります。私abstract classはそれを使用します：

public interface ITypeNameMapper
{
    string Map(TypeDefinition typeDefinition);
}

public abstract class TypeNameMapper : ITypeNameMapper
{
    public virtual string Map(TypeDefinition typeDefinition)
    {
        if (typeDefinition is ClassDefinition classDefinition)
        {
            return Map(classDefinition);
        }
        ...

        throw new ArgumentOutOfRangeException(nameof(typeDefinition));
    }

    protected abstract string Map(ClassDefinition classDefinition);
}

ご覧のとおり、インターフェイスもありますITypeNameMapper。私がすでに抽象クラスを持っているTypeNameMapperか、それでabstract class十分な場合、このインターフェイスを定義するのは理にかなっていますか？

TypeDefinition この最小限の例でも抽象的です。

はい、C＃ではインターフェイスを除き複数の継承を許可しないためです。

したがって、TypeNameMapperとSomethingelseMapperの両方であるクラスがある場合、次のことができます。

class MultiFunctionalClass : ITypeNameMapper, ISomethingelseMapper 
{
    private TypeNameMapper map1
    private SomethingelseMapper map2

    public string Map(TypeDefinition typeDefinition) { return map1.Map(typeDefintion);}

    public string Map(OtherDef otherDef) { return map2.Map(orderDef); }
}

インターフェイスと抽象クラスの目的は次のとおりです。

• インターフェイスはAPIを定義し、実装ではなくクライアントに属します。
• クラスが実装を共有する場合、抽象クラスの恩恵を受けることができます。

この例でinterface ITypeNameMapperは、クライアントのニーズを定義し、abstract class TypeNameMapper値を追加していません。

インターフェイスの概念全体は、共有APIを持つクラスのファミリをサポートするために作成されました。

これは、インターフェースの使用は、その仕様の実装が複数あることを意味することを明示的に言っています。

DIフレームワークは、実装が1つしかない場合でも、多くの場合インターフェイスが必要なため、ここで水を汚しました-私にとって、これはほとんどの場合、新しい呼び出しのより複雑で遅い手段であるために不合理なオーバーヘッドですが、それが何であるかです。

答えは質問自体にあります。抽象クラスがある場合、共通のAPIを使用して複数の派生クラスを作成する準備をしています。したがって、インターフェースの使用が明確に示されています。

質問に明示的に答えたい場合、著者は、「抽象クラスTypeNameMapperを既に持っている場合、または抽象クラスで十分な場合、このインターフェイスを定義しても意味がありますか？」と言います。

はいインターフェイスがない場合の抽象基本クラス。

構築しようとしているAPIについて十分に考えていないことは明らかです。最初にAPIを作成し、必要に応じて部分的な実装を提供します。抽象基本クラスがコードの型チェックを行うという事実は、それが正しい抽象化ではないことを伝えるのに十分です。

OODのほとんどの場合と同様に、グルーブに入ってオブジェクトモデルを適切に処理すると、コードから次に何が来るかが通知されます。インターフェースから始めて、必要なクラスにそのインターフェースを実装します。同様のコードを書いていることに気付いたら、それを抽象基本クラスに抽出します-それが重要なインターフェースであり、抽象基本クラスは単なるヘルパーであり、複数ある場合があります。

これは、アプリケーションの残りの部分を知らずに答えることは非常に困難です。

ある種のDIモデルを使用しており、コードを可能な限り拡張可能に設計していると仮定すると（そうすればTypeNameMapper簡単に新しいものを追加できます）、私はイエスと言います。

の理由：

• 基本クラスが実装するため、効果的に無料で入手できinterfaceます。どの子実装でも心配する必要はありません
• ほとんどのIoCフレームワークとモッキングライブラリはを期待していinterfaceます。それらの多くは抽象クラスで動作しますが、それは常に与えられているわけではなく、可能な限りライブラリの他の99％のユーザーと同じ道をたどることを強く信じています。

以下に対する理由：

• 厳密に言えば（あなたが指摘したように）あなたは本当にする必要はありません
• class/ interfaceが変更された場合、少しオーバーヘッドが追加されます

すべてのことを考慮して、私はあなたがinterface。その理由はごくわずかですが、モックやIoCでアブストラクトを使用することは可能ですが、多くの場合、インターフェイスを使用する方がはるかに簡単です。しかし、最終的には、同僚のコードが反対になっても、私は同僚のコードを批判しません。