méthode statique ne peut pas mettre en œuvre la méthode de l'interface, pourquoi?

interface IXXX
{
    void Foo();
}

class XXX : IXXX
{
    public static void Foo()
    {
        Console.WriteLine("From XXX");
    }
}


class Program 
{
    static void Main(string[] args)
    {
        XXX.Foo();

    }
}

Erreur de compilateur: XXX.Foo() ne peut pas implémenter une interface membre parce qu'il est statique.

Pourquoi pas une méthode statique de mettre en œuvre une méthode d'interface?

Il ne fait pas de sens. Comment voulez-vous mettre en œuvre l'interface dans une classe dérivée de XXX? Il n'ya aucune raison vous ne pouvez pas appeler le membre statique de la mise en œuvre.
stackoverflow.com/questions/259026/...
vous de type "méthode"; où il n'y avait pas un implicite this mais il n'a résoudre la méthode au moment de l'exécution de ce type. Les rares occasions qui les utilisent peuvent être favorisées par des méthodes d'instance ou de réflexion, donc pas un besoin pressant de l'OMI.
Hanna: Vous pouvez, mais le compilateur puisse se plaindre de ne pas être en mesure de résoudre la bonne méthode.
Avec la réflexion technique, il ne pouvait pas, avec l'utilisation de la méthode d'instance qu'il le pouvait. La nécessité de presse assez pour exiger un changement de langue? Je dirais que non IMO si j'ai parfois voulu moi-même.

OriginalL'auteur xport | 2010-10-18

  1. 11

    Voir ce fil de JoelOnSoftware décrivant les raisons derrière tout cela.

    Fondamentalement, l'interface est le contrat entre le consommateur et le fournisseur, et une méthode statique appartient à la classe, et non pas de chaque instance de la classe en tant que telle.

    Une question précédente sur DONC aussi traiter avec exactement la même question:
    Pourquoi Ne pas C# Permettent de Méthodes Statiques pour Implémenter une Interface?

    OriginalL'auteur Øyvind Bråthen

  2. 4

    Une interface définit le comportement d'un objet doit répondre.
    Que Foo est une méthode statique, l'objet ne répond pas. En d'autres termes, vous ne pouviez pas écrire...

    XXX myXXX = new XXX();
myXXX.Foo();

    En d'autres termes, myXXX ne pas satisfaire pleinement aux exigences de l'interface.

    OriginalL'auteur Richard Fawcett

  3. 2

    SI l'on regarde les interfaces comme une promesse qu'un objet peut effectuer l'une des méthodes indiquées dans l'interface, puis sat idée de la statique de la mise en œuvre devient problématique. Si le implemetion est statique, alors vous ne pouvez pas écrire de nouvelles ImplementingObject().ImplementedMthod. L'objet ne peut pas exécuter la méthode, la classe peut.

    OriginalL'auteur Neowizard

  4. 2

    Vous utilisez l'interface pour éviter d'utiliser la classe de béton lors de l'instanciation. Vous ne pouvez pas accéder méthode statique à travers instancié de la classe, de sorte que la mise en œuvre de méthodes d'interface avec des méthodes statiques n'est pas autorisé.

    OriginalL'auteur Tomek

  5. 1

    Bien, je crois qu'il devrait autorisées en cas d'paramètre de type générique. C'est probablement simplifié contractuelles classe singleton. Voici un exemple:

    public interface IEntity {
   //some constrains...
  DataRow ObjToRow(object obj);
  object RowToObj(DataRow dr);
}

//T would be any class inherites from IEntity with default contructor signature.
public interface IMyContract {
  T read<T>() where T : IEntity;  
  void write<T>(T object) where T : IEntity;
}

//everything in the class is static
public static class SqlProvider : IMyContract {

  public static T read<T>() where T: IEntity {
    DataRow dr = [reading from database]
    return T.RowToObj(dr);
  }

  //compile error here....
  public static void write<T>(T obj) where T : IEntity {
    DataRow dr = T.ObjToRow(obj);

   [ ... commit data row dr to database ... ]

  }
}

public static class MyAppleEntity : IEntity  {
  [... implement IEntity contract normally ... ]
}

public static class MyOrangeEntity : IEntity {
   [... implement IEntity contract normally ... ]
}

public class MyTest {
  void reading() {
     MyAppleEntity apple = SqlProvider.Read<MyAppleEntity>();
     MyOrangeEntity orange = SqlProvider.Read<MyOrangeEntity>();

     SqlProvider.write<MyAppleEntity>(apple); 
     SqlProvider.write<MyOrangeEntity>(orange);
  } 

}

    Le seul moment où un type de référence est implicitement dans le SqlProvider.read() et write() et T est bien une identité au point de l'appeler. Sans statique de la mise en œuvre de l'interface, je suis obligé d'écrire comme cela.

    public class MyAppleEntity : IEntity  {
  [... implement IEntity contract normally ... ]
}

  .....

  public T read<T>() where T: IEntity, new() {
    DataRow dr = [reading from database]
    return new T().RowToObj(dr);
  }

    Très peu différent mais pas tout à fait élégant.

    Je crois que c'est ce que les langages fonctionnels appeler un "foncteur'.

    OriginalL'auteur Leng

  6. 0

    Parce que l'interface de membre sont publiques et substituables, et que la méthode statique ne peut pas, par conception, être surdéfini ou abstraites, Interfaces sont ici pour définir un accessibles contrat qui doit être mis en œuvre par leur mise en œuvre concrète (avec autant d'étapes de l'abstraction implémentations & interfaces héritées entre) et autant que je sache, il n'y a aucun moyen de créer un résumé, la méthode statique.

    OriginalL'auteur dvhh