Raisons impérieuses d'utiliser des interfaces de marquage plutôt que des attributs

Question

Il a été discuté précédemment sur Stack Overflow que nous devrions préférer les attributs aux interfaces de marquage (interfaces sans aucun membre). Article sur la conception d'interfaces sur MSDN affirme également cette recommandation :

Évitez d'utiliser des interfaces de marquage (interfaces sans membres).

Les attributs personnalisés permettent de marquer un type. Pour plus d'informations sur les attributs personnalisés, voir Écrire des attributs personnalisés. Les attributs personnalisés sont préférables lorsque vous pouvez différer la vérification de l'attribut jusqu'à l'exécution du code. Si votre scénario exige une vérification au moment de la compilation, vous ne pouvez pas vous conformer à cette ligne directrice.

Il y a même un Règle FxCop pour mettre en œuvre cette recommandation :

Éviter les interfaces vides

Les interfaces définissent des membres qui fournissent un comportement ou un contrat d'utilisation. La fonctionnalité décrite par l'interface peut être adoptée par n'importe quel type, quelle que soit sa position dans la hiérarchie de l'héritage. Un type implémente une interface en fournissant des implémentations pour les membres de l'interface. Une interface vide ne définit aucun membre et, en tant que telle, ne définit pas de contrat pouvant être mis en œuvre.

Si votre conception inclut des interfaces vides que les types sont censés implémenter, vous utilisez probablement une interface comme marqueur, ou comme moyen d'identifier un groupe de types. Si cette identification doit avoir lieu au moment de l'exécution, la bonne façon d'y parvenir est d'utiliser un attribut personnalisé. Utilisez la présence ou l'absence de l'attribut, ou les propriétés de l'attribut, pour identifier les types cibles. Si l'identification doit avoir lieu à la compilation, l'utilisation d'une interface vide est acceptable.

L'article ne mentionne qu'une seule raison pour laquelle vous pouvez ignorer l'avertissement : lorsque vous avez besoin d'une identification des types au moment de la compilation. (Ceci est cohérent avec l'article sur la conception des interfaces).

Il est possible d'exclure un avertissement de cette règle si l'interface est utilisée pour identifier un ensemble de types au moment de la compilation.

Voici la question proprement dite : Microsoft n'a pas respecté ses propres recommandations dans la conception de la Framework Class Library (au moins dans quelques cas) : Interface IRequiresSessionState y Interface IReadOnlySessionState . Ces interfaces sont utilisées par le cadre ASP.NET pour vérifier s'il doit activer l'état de session pour un gestionnaire spécifique ou non. De toute évidence, elles ne sont pas utilisées pour l'identification des types au moment de la compilation. Pourquoi n'ont-ils pas fait cela ? Je vois deux raisons possibles :

1. Micro-optimisation : Vérification de l'implémentation d'une interface par un objet ( obj is IReadOnlySessionState ) est plus rapide que l'utilisation de la réflexion pour vérifier la présence d'un attribut ( type.IsDefined(typeof(SessionStateAttribute), true) ). La différence est négligeable la plupart du temps, mais elle peut avoir de l'importance pour un chemin de code critique en termes de performances dans le moteur d'exécution ASP.NET. Cependant, il existe des solutions de contournement, comme la mise en cache du résultat pour chaque type de gestionnaire. Ce qui est intéressant, c'est que les services Web ASMX (qui sont soumis à des caractéristiques de performance similaires) utilisent en fait la fonction EnableSession propriété de la WebMethod attribut à cette fin.

2. La mise en œuvre d'interfaces est potentiellement plus susceptible d'être prise en charge que la décoration de types avec des attributs par des langages .NET tiers. Puisque ASP.NET est conçu pour être agnostique en matière de langage, et que ASP.NET génère du code pour les types (éventuellement dans un langage tiers à l'aide de la fonction CodeDom ) qui mettent en œuvre lesdites interfaces sur la base de la EnableSessionState de l'attribut <%@ Page %> directive il serait peut-être plus judicieux d'utiliser des interfaces plutôt que des attributs.

Quelles sont les raisons convaincantes d'utiliser des interfaces de marqueurs plutôt que des attributs ?

S'agit-il simplement d'une optimisation (prématurée ?) ou d'une petite erreur dans la conception du cadre ? (Pensent-ils que le reflet est un "grand monstre aux yeux rouges" ?) Réflexions ?

Answer 1

J'évite généralement les "interfaces de marquage" parce qu'elles ne permettent pas de démarquer un type dérivé. Mais cela mis à part, voici quelques cas spécifiques que j'ai vus où les interfaces de marquage seraient préférables à un support de méta-données intégré :

1. Situations sensibles du point de vue des performances d'exécution.
2. Compatibilité avec les langages qui ne supportent pas les annotations ou les attributs.
3. Tout contexte dans lequel le code intéressé n'a pas accès aux métadonnées.
4. Prise en charge des contraintes génériques et de la variance générique (typiquement des collections).

Answer 2

Pour un type générique, on peut vouloir utiliser le même paramètre générique dans une interface de marquage. Cela n'est pas possible avec un attribut :

interface MyInterface<T> {}

class MyClass<T, U> : MyInterface<U> {}

class OtherClass<T, U> : MyInterface<IDictionary<U, T>> {}

Ce type d'interface peut être utile pour associer un type à un autre.

Une autre bonne utilisation d'une interface de marquage est la création d'un type de mélangeur :

interface MyMixin {}

static class MyMixinMethods {
  public static void Method(this MyMixin self) {}
}

class MyClass : MyMixin {
}

En modèle de visiteur acyclique les utilise également. Le terme "interface dégénérée" est également parfois utilisé.

UPDATE :

Je ne sais pas si cela compte, mais je les ai utilisés pour noter les cours d'une école. post-compilateur à travailler.

Answer 3

Microsoft n'a pas suivi strictement les lignes directrices lorsqu'il a créé .NET 1.0, parce que les lignes directrices ont évolué en même temps que le cadre, et que certaines règles n'ont été apprises que lorsqu'il était trop tard pour modifier l'API.

IIRC, les exemples que vous mentionnez appartiennent à BCL 1.0, ce qui expliquerait cela.

Ceci est expliqué dans Lignes directrices pour la conception du cadre .

---

Cela dit, le livre fait également remarquer que "[l]es tests d'attributs sont beaucoup plus coûteux que la vérification de type" (dans un encadré de Rico Mariani).

Il ajoute que l'on a parfois besoin de l'interface du marqueur pour effectuer des vérifications au moment de la compilation, ce qui n'est pas possible avec un attribut. Cependant, l'exemple donné dans le livre (p. 88) n'est pas convaincant et je ne le répéterai donc pas ici.

Answer 4

Je suis très favorable à Marker Interfaces. Je n'ai jamais aimé Attributs. Je les vois comme une sorte de méta-information pour les classes et les membres, destinée par exemple aux débogueurs. Comme pour les exceptions, ils ne devraient pas influencer la logique de traitement normale, à mon humble avis.

Answer 5

Du point de vue du codage, je pense que je préfère la syntaxe de l'interface du marqueur en raison des mots-clés intégrés. as y is . Le marquage des attributs nécessite un peu plus de code.

[MarkedByAttribute]
public class MarkedClass : IMarkByInterface
{
}

public class MarkedByAttributeAttribute : Attribute
{
}

public interface IMarkByInterface
{
}

public static class AttributeExtension
{
    public static bool HasAttibute<T>(this object obj)
    {
        var hasAttribute = Attribute.GetCustomAttribute(obj.GetType(), typeof(T));
        return hasAttribute != null;
    }
}

Et quelques tests pour utiliser le code :

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class ClassMarkingTests
{
    private MarkedClass _markedClass;

    [TestInitialize]
    public void Init()
    {
        _markedClass = new MarkedClass();
    }

    [TestMethod]
    public void TestClassAttributeMarking()
    {
        var hasMarkerAttribute = _markedClass.HasAttibute<MarkedByAttributeAttribute>();
        Assert.IsTrue(hasMarkerAttribute);
    }

    [TestMethod]
    public void TestClassInterfaceMarking()
    {
        var hasMarkerInterface = _markedClass as IMarkByInterface;
        Assert.IsTrue(hasMarkerInterface != null);            
    }
}