分類のみにインターフェースを使用するのは悪い習慣ですか？

例えば：

私はクラスを持っていると言いますA、B、C。私は2つのインタフェースを持って、それらを呼び出すことができますIAnimalし、IDog。IDogから継承しIAnimalます。Aand BはIDogsで、while Cはそうではありませんが、IAnimalです。

重要な部分は、IDog追加機能を提供しないことです。特定のメソッドへの引数として渡されることを許可するためだけに使用されますがA、BではありませんC。

これは悪い習慣ですか？

メンバーを持たないインターフェイス、またはマーカーインターフェイスと呼ばれる同じインターフェイスから継承される別のインターフェイスとまったく同じメンバーを持つインターフェイスで、それをマーカーとして使用しています。

悪い習慣ではありませんが、使用している言語がサポートしている場合、インターフェースを属性（注釈）に置き換えることができます。

Orchard Projectで頻繁に使用される「Marker Interface」パターンを見たので、悪い習慣ではないと自信を持って言うことができます

Orchardプロジェクトのサンプルを次に示します。

public interface ISingletonDependency : IDependency {}

/// <summary>
/// Base interface for services that may *only* be instantiated in a unit of work.
/// This interface is used to guarantee they are not accidentally referenced by a singleton dependency.
/// </summary>
public interface IUnitOfWorkDependency : IDependency {}

/// <summary>
/// Base interface for services that are instantiated per usage.
/// </summary>
public interface ITransientDependency : IDependency {}

Marker Interfaceを参照してください。

はい、それはほとんどすべての言語で悪い習慣です。

データをエンコードするための型はありません。それらは、データが行きたい場所に行き、振る舞う必要があるように振る舞うことを証明する助けとなります。サブタイプを設定する唯一の理由は、ポリモーフィックな動作が変更された場合です（常にそうではありません）。

タイピングがないので、IDogができることは暗示されています。あるプログラマーはあることを考え、別のプログラマーは別のことを考え、物事は崩壊します。または、よりきめ細かい制御が必要になると、それが表すものが増えます。

[編集：明確化]

つまり、インターフェイスに基づいて何らかのロジックを実行しているということです。一部の方法は犬と他の動物でしか機能しないのはなぜですか？違いを提供する実際のメンバーがないため、その違いは暗黙の契約です。システムに実際のデータはありません。唯一の違いはインターフェイスです（したがって、「入力しない」コメント）。その意味はプログラマによって異なります。[/編集]

特定の言語は、これがそれほど悪くない特性メカニズムを提供しますが、洗練ではなく機能に焦点を合わせる傾向があります。私は彼らとはほとんど経験がないので、そこでのベストプラクティスについて話すことはできません。C ++ / Java / C＃では...良くありません。

私はC＃のみを知っているので、一般的なオブジェクト指向プログラミングではこれを言えませんが、C＃の例として、クラスを分類する必要がある場合、明らかなオプションはインターフェイス、列挙型プロパティ、またはカスタム属性です。通常、他の人が何を考えているかに関係なく、インターフェイスを選択します。

if(animal is IDog)
{
}
if(animal.Type == AnimalType.Dog)
{
}
if(animal.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any())
{
}


var dogs1 = animals.OfType<IDog>();
var dogs2 = animals.Where(a => a.Type == AnimalType.Dog);
var dogs3 = animals.Where(a => a.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any());


var dogsFromDb1 = session.Query<IDog>();
var dogsFromDb2 = session.Query<Animal>().Where(a => a.Type == AnimalType.Dog);
var dogsFromDb3 = session.Query<Animal>().Where(a => a.GetType().GetCustomAttributes(typeof(DogAttribute),false).Any());


public void DoSomething(IDog dog)
{
}
public void DoSomething(Animal animal)
{
    if(animal.Type != AnimalType.Dog)
    {
        throw new ArgumentException("This method should be used for dogs only.");
    }
}
public void DoSomething(Animal animal)
{
    if(!animal.GetType().GetCustomAttributes(typeof(DogAttribute), false).Any())
    {
        throw new ArgumentException("This method should be used for dogs only.");
    }
}

後者のインターフェースのすべての実装が前者のいくつかの実装ではできないことを有用に行えると予想される場合、新しいメンバーを追加せずに別のインターフェースを継承するインターフェースを持つことには何の問題もありません。確かに、より派生したインターフェイスによって暗示される制約をクラスが自然に満たす実装者は、より派生したインターフェイスを単に実装することで示すことができるため、。 、メンバー実装コードまたは宣言を変更する必要はありません。

たとえば、インターフェイスがあるとします：

インターフェースIMaybeMutableFoo {
  Bar Thing {get; set;} //その他のプロパティも
  bool IsMutable;
  IImmutableFoo AsImmutable（）;
}
インターフェースIImmutableFoo：IMaybeMutableFoo {};

の実装はIImmutableFoo.AsImmutable()それ自体を返すことが期待されます。実装可能な可変クラスIMaybeMutableFoo.AsImmutable()は、データのスナップショットを含む新しい深く不変のオブジェクトを返すことが期待されます。に保持されているデータのスナップショットを保存するルーチンは、IMaybeMutableFooオーバーロードを提供する可能性があります。

public void StoreData（IImmutableFoo ThingToStore）
{
  // ThingToStoreは不変であることが知られているため、参照を保存するだけで十分です。
}
public void StoreData（IMaybeMutableFoo ThingToStore）
{
  StoreData（ThingToStore.AsImmutable（））; //より具体的なオーバーロードを呼び出します
}

コンパイラーは、保存されるものがであることを知らない場合、IImmutableFooを呼び出しますAsImmutable()。アイテムが既に不変である場合、関数はすぐに戻りますが、インターフェイスを介した関数呼び出しにはまだ時間がかかります。コンパイラは、アイテムが既にであることを知っている場合、IImmutableFoo不要な関数呼び出しをスキップできます。