Est-ce une mauvaise pratique d'utiliser une interface pour la catégorisation uniquement?

Par exemple:

Dire que j'ai des classes A, B, C. J'ai deux interfaces, appelons-les IAnimalet IDog. IDoghérite de IAnimal. Aet Bsont IDogs, tandis que Cne l'est pas, mais c'est un IAnimal.

La partie importante est qu'elle IDogne fournit aucune fonctionnalité supplémentaire. Il est uniquement utilisé pour autoriser Aet B, mais pas C, être passé en argument à certaines méthodes.

Est-ce une mauvaise pratique?

Interface qui n'a aucun membre ou qui a exactement les mêmes membres avec une autre interface héritée de la même interface appelée Interface de marqueur et que vous l'utilisez comme marqueur.

Ce n'est pas une mauvaise pratique mais l'interface peut être remplacée par des attributs (annotations) si la langue que vous utilisez la prend en charge.

Je peux dire en toute confiance que ce n'est pas une mauvaise pratique parce que j'ai vu un modèle "d'interface de marqueur" à forte utilisation dans le projet Orchard

Voici un exemple du projet 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 {}

Veuillez vous référer à l' interface des marqueurs .

Oui, c'est une mauvaise pratique dans presque toutes les langues.

Les types ne sont pas là pour coder les données; ils sont une aide pour prouver que vos données vont là où elles doivent aller et se comportent comme elles doivent se comporter. La seule raison de sous-taper est si un comportement polymorphe change (et pas toujours alors).

Puisqu'il n'y a pas de saisie, ce qu'un IDog peut faire est implicite. Un programmeur pense une chose, un autre en pense une autre et les choses tombent en panne. Ou les choses qu'il représente augmentent à mesure que vous avez besoin d'un contrôle plus fin.

[modifier: clarification]

Ce que je veux dire, c'est que vous faites une logique basée sur l'interface. Pourquoi certaines méthodes ne peuvent-elles fonctionner qu'avec des chiens et d'autres avec n'importe quel animal? Cette différence est un contrat implicite puisqu'il n'y a aucun membre réel qui fournit la différence; aucune donnée réelle dans le système. La seule différence est l'interface (d'où le commentaire «pas de frappe»), et ce que cela signifie différera entre les programmeurs. [/Éditer]

Certains langages fournissent des mécanismes de traits là où ce n'est pas trop mal, mais ceux-ci ont tendance à se concentrer sur les capacités, pas sur le raffinement. J'ai peu d'expérience avec eux, donc je ne peux pas parler des meilleures pratiques là-bas. En C ++ / Java / C # cependant ... pas bon.

Je ne connais bien que C #, donc je ne peux pas dire cela pour la programmation OO en général, mais comme exemple C #, si vous devez catégoriser les classes, les options évidentes sont les interfaces, la propriété enum ou les attributs personnalisés. Habituellement, je choisirais l'interface, peu importe ce que les autres pensent.

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.");
    }
}

Il n'y a rien de mal à avoir une interface qui hérite d'une autre interface sans ajouter de nouveaux membres, si toutes les implémentations de cette dernière interface sont censées être capables de faire utilement des choses que certaines implémentations de la première peuvent ne pas faire. En effet, c'est un bon modèle qui à mon humble avis aurait dû être utilisé plus dans des choses comme le .net Framework, d'autant plus qu'un implémenteur dont la classe satisferait naturellement les contraintes impliquées par l'interface plus dérivée peut indiquer que simplement en implémentant l'interface plus dérivée , sans avoir à modifier le code ou les déclarations d'implémentation des membres.

Par exemple, supposons que j'ai les interfaces:

interface IMaybeMutableFoo {
  Bar Thing {get; set;} // Et d'autres propriétés également
  bool IsMutable;
  IImmutableFoo AsImmutable ();
}
interface IImmutableFoo: IMaybeMutableFoo {};

Une implémentation de IImmutableFoo.AsImmutable()devrait se retourner; une implémentation de classe mutable IMaybeMutableFoo.AsImmutable()devrait renvoyer un nouvel objet profondément immuable contenant un instantané des données. Une routine qui veut stocker un instantané des données contenues dans un IMaybeMutableFoopourrait offrir des surcharges:

public void StoreData (IImmutableFoo ThingToStore)
{
  // Le stockage de la référence suffira, car ThingToStore est connu pour être immuable
}
public void StoreData (IMaybeMutableFoo ThingToStore)
{
  StoreData (ThingToStore.AsImmutable ()); // Appelle la surcharge plus spécifique
}

Dans les cas où le compilateur ne sait pas que la chose à stocker est un IImmutableFoo, il appellera AsImmutable(). La fonction doit retourner rapidement si l'élément est déjà immuable, mais un appel de fonction via une interface prend encore du temps. Si le compilateur sait que l'élément est déjà un IImmutableFoo, il peut ignorer l'appel de fonction inutile.