Pourquoi C# ne permet-il pas aux méthodes statiques d'implémenter une interface ?

Question

Pourquoi le C# a-t-il été conçu de cette manière ?

D'après ce que j'ai compris, une interface ne fait que décrire un comportement, et sert à décrire une obligation contractuelle pour les classes qui implémentent l'interface de mettre en œuvre un certain comportement.

Si les classes souhaitent implémenter ce comportement dans une méthode partagée, pourquoi ne le feraient-elles pas ?

Voici un exemple de ce que j'ai en tête :

// These items will be displayed in a list on the screen.
public interface IListItem {
  string ScreenName();
  ...
}

public class Animal: IListItem {
    // All animals will be called "Animal".
    public static string ScreenName() {
        return "Animal";
    }
....
}

public class Person: IListItem {

    private string name;

    // All persons will be called by their individual names.
    public string ScreenName() {
        return name;
    }

    ....

 }

Answer 1

En supposant que vous vous demandez pourquoi vous ne pouvez pas le faire :

public interface IFoo {
    void Bar();
}

public class Foo: IFoo {
    public static void Bar() {}
}

Cela n'a pas de sens pour moi, sémantiquement. Les méthodes spécifiées sur une interface devraient être là pour spécifier le contrat d'interaction avec un objet. Les méthodes statiques ne vous permettent pas d'interagir avec un objet. Si vous vous trouvez dans une situation où votre implémentation pourrait être rendue statique, vous devez vous demander si cette méthode appartient vraiment à l'interface.

---

Pour mettre en œuvre votre exemple, je donnerais à Animal une propriété const, ce qui lui permettrait encore d'être accessible à partir d'un contexte statique, et je renverrais cette valeur dans l'implémentation.

public class Animal: IListItem {
    /* Can be tough to come up with a different, yet meaningful name!
     * A different casing convention, like Java has, would help here.
     */
    public const string AnimalScreenName = "Animal";
    public string ScreenName(){ return AnimalScreenName; }
}

Pour une situation plus complexe, vous pouvez toujours déclarer une autre méthode statique et la déléguer. En essayant de trouver un exemple, je n'ai trouvé aucune raison de faire quelque chose de non trivial à la fois dans un contexte statique et dans un contexte d'instance, donc je vous épargnerai un blob de FooBar, et le prendrai comme une indication que ce n'est peut-être pas une bonne idée.

Answer 2

Ma raison technique (simplifiée) est que les méthodes statiques ne font pas partie de l'environnement de l'entreprise. vtable et le site d'appel est choisi au moment de la compilation. C'est la même raison pour laquelle vous ne pouvez pas avoir de membres statiques surchargés ou virtuels. Pour plus de détails, vous aurez besoin d'un diplômé de CS ou d'un compilateur - ce que je ne suis ni l'un ni l'autre.

Pour la raison politique, je vais Citation d'Eric Lippert (qui est un compilateur wonk, et détient une licence en mathématiques, informatique et mathématiques appliquées de l'Université de Waterloo (source : LinkedIn ) :

...le principe de conception central des méthodes statiques, le principe qui leur donne leur nom... [est]... on peut toujours déterminer exactement, au moment de la compilation, quelle méthode sera appelée. C'est-à-dire que la méthode peut être résolue uniquement par l'analyse statique du code.

Notez que Lippert laisse une place à une méthode dite de type :

C'est-à-dire une méthode associée à un type (comme une statique), qui ne prend pas d'argument "this" non nul (contrairement à une instance ou une virtuelle), mais une méthode dont l'appel dépend du type construit de T (contrairement à une statique, qui doit pouvoir être déterminée au moment de la compilation).

mais doit encore être convaincu de son utilité.

Answer 3

La plupart des réponses ici semblent passer à côté de l'essentiel. Le polymorphisme peut être utilisé non seulement entre les instances, mais aussi entre les types. Ceci est souvent nécessaire, lorsque nous utilisons des génériques.

Supposons que nous ayons un paramètre de type dans une méthode générique et que nous devions effectuer une opération avec lui. Nous ne voulons pas faire d'instantanéité, car nous ne connaissons pas les constructeurs.

Par exemple :

Repository GetRepository<T>()
{
  //need to call T.IsQueryable, but can't!!!
  //need to call T.RowCount
  //need to call T.DoSomeStaticMath(int param)
}

...
var r = GetRepository<Customer>()

Malheureusement, je ne peux proposer que des alternatives "moches" :

• Utiliser la réflexion Moche et qui bat l'idée des interfaces et du polymorphisme.

• Créer une classe d'usine complètement distincte

  Cela pourrait augmenter considérablement la complexité du code. Par exemple, si nous essayons de modéliser des objets de domaine, chaque objet aurait besoin d'une autre classe de référentiel.

• Instanciez et appelez ensuite la méthode de l'interface souhaitée.

  Cela peut être difficile à mettre en œuvre même si nous contrôlons la source des classes, utilisées comme paramètres génériques. La raison en est que, par exemple, nous pourrions avoir besoin que les instances soient uniquement dans un état bien connu, "connecté à la base de données".

Exemple :

public class Customer 
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  void SomeOtherMethod() 
  { 
    //do work...
  }
}

afin d'utiliser l'instantination pour résoudre le problème de l'interface statique, nous devons faire la chose suivante :

public class Customer: IDoSomeStaticMath
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  //dummy instance
  public Customer() { IsDummy = true; }

  int DoSomeStaticMath(int a) { }

  void SomeOtherMethod() 
  { 
    if(!IsDummy) 
    {
      //do work...
    }
  }
}

Cela est évidemment laid et complique inutilement le code de toutes les autres méthodes. Évidemment, ce n'est pas non plus une solution élégante !

Answer 4

Je sais que c'est une vieille question, mais c'est intéressant. L'exemple n'est pas le meilleur. Je pense que ce serait beaucoup plus clair si vous montriez un cas d'utilisation :

string DoSomething<T>() where T:ISomeFunction
{
  if (T.someFunction())
    ...
}

Le simple fait de pouvoir disposer de méthodes statiques mettre en œuvre une interface ne permettrait pas d'obtenir ce que vous voulez ; ce qui serait nécessaire serait d'avoir des membres statiques en tant que partie d'une interface. Je peux certainement imaginer de nombreux cas d'utilisation pour cela, en particulier lorsqu'il s'agit de pouvoir créer des choses. Je pourrais proposer deux approches qui pourraient être utiles :

1. Créez une classe générique statique dont le paramètre de type sera le type que vous passerez à DoSomething ci-dessus. Chaque variation de cette classe aura un ou plusieurs membres statiques contenant des informations relatives à ce type. Ces informations peuvent être fournies soit en demandant à chaque classe concernée d'appeler une routine d'enregistrement des informations, soit en utilisant Reflection pour obtenir les informations lorsque le constructeur statique de la variation de la classe est exécuté. Je crois que cette dernière approche est utilisée par des choses comme Comparer<T>.Default().
2. Pour chaque classe T d'intérêt, définissez une classe ou une structure qui implémente IGetWhateverClassInfo<T> et satisfait à la contrainte "new". La classe ne contiendra pas réellement de champs, mais aura une propriété statique qui renvoie un champ statique avec les informations de type. Passez le type de cette classe ou structure à la routine générique en question, qui sera capable de créer une instance et de l'utiliser pour obtenir des informations sur l'autre classe. Si vous utilisez une classe dans ce but, vous devriez probablement définir une classe générique statique comme indiqué ci-dessus, pour éviter de devoir construire une nouvelle instance de descripteur-objet à chaque fois. Si vous utilisez une structure, le coût d'instanciation devrait être nul, mais chaque type de structure différent nécessitera une expansion différente de la routine DoSomething.

Aucune de ces approches n'est vraiment attrayante. D'un autre côté, je m'attendrais à ce que si les mécanismes existaient dans CLR pour fournir ce genre de fonctionnalité proprement, .net permettrait de spécifier des contraintes "new" paramétrées (puisque savoir si une classe a un constructeur avec une signature particulière semblerait être une difficulté comparable à celle de savoir si elle a une méthode statique avec une signature particulière).

Answer 5

Les interfaces spécifient le comportement d'un objet.

Les méthodes statiques ne spécifient pas le comportement d'un objet, mais un comportement qui affecte un objet d'une certaine manière.