C# appel de la méthode de l'interface au sein de la classe

interface ILol
{
   void LOL();
}

class Rofl : ILol
{
   void ILol.LOL()
   {
      GlobalLOLHandler.RaiseROFLCOPTER(this);
   }
   public Rofl()
   {
      //Is there shorter way of writing this or i is there "other" problem with implementation??
      (this as ILol).LOL();
   }
}
Essayez d'éviter d'appeler le "virtuel" de fonctions à partir d'un constructeur! Vous pouvez retrouvez l'appel d'une application qui accède à un pas entièrement à l'objet construit.

OriginalL'auteur 0xDEAD BEEF | 2010-05-10

  1. 10

    Vous avez mis en œuvre l'interface explicitement qui, en général, vous n'avez pas besoin de le faire. Au lieu de cela, juste la mettre en œuvre de manière implicite et l'appeler comme vous le feriez pour tout autre méthode:

    class Rofl : ILol
{
    public void LOL() { ... }

    public Rofl()
    {
        LOL();
    }
}

    (Note de votre mise en œuvre devra également être public.)

    Vous vous rendez compte de votre exemple de code en œuvre explicitement encore, non? 🙂
    Bon dieu, c'est embarrassant. Fixe - merci!!!!!
    Quelle est la différence entre implicite et explicite de la mise en œuvre? Si je n'ajoute pas ILol. avant de LOL, alors le compilateur se plaint qu'il n'y a pas d'implémentation de ILol.LOL.
    Des interfaces explicites ne peut être appelée lorsque l'objet est converti dans le type d'interface. Il existe différents obscur avantages à cela, mais sinon, il faut l'éviter. Quant à savoir pourquoi ton code ne fonctionne pas, je ne peux que deviner: les méthodes qui implémentent l'interface accessible au public?
    Pour clarifier: ce ladenedge est dit dans le commentaire ci-dessus, c'est que l'OP nécessaire pour ajouter public en face de sa déclaration, lorsqu'il prit ILol..

    OriginalL'auteur ladenedge

  2. 9

    Vous pouvez modifier la distribution de (this as ILol) à ((ILol)this). Une coulée est autorisé à retourner la valeur null, ce qui pourrait causer de la confusion des erreurs plus tard et dont le compilateur a tester.

    Revenir? Quel est le problème avec le as fonte, par rapport à la non-as?
    À l'aide de l'objet renvoyé de as avant de vérifier la valeur null est une mauvaise pratique. Le code ci-dessus ne présentent pas tous les problèmes comme l'écrit, mais qui ne sont pas aussi résistants au cours de refactoring.
    La coulée peut retourner la valeur null, alors le compilateur a besoin de tester la valeur null avant d'appeler la méthode de sorte qu'il peut générer la référence nulle exception. régulièrement cast ne peut jamais retourner la valeur null si le compilateur ne peut éluder le test de la valeur null.
    La discussion ci-dessus pourraient confondre quelqu'un qui a récemment appris à utiliser as, afin qu'ils puissent gérer les situations où un objet ne peut pas être converti dans le type de cible. La règle est: si vous n'êtes pas certain à 100% que le casting sera toujours valide, utilisez as, puis sur test si le résultat est null. Si elle ne peut pas échouer [ici, nous savons this est un ILol, car elle est définie à l'être], puis le faire directement en fonte, (ILol).

    OriginalL'auteur Stewart

  3. 5

    Ne pas utiliser as, juste lancer:

    ((ILol)this).LOL();

    OriginalL'auteur Mark Byers

  4. 0

    Non, pas si vous êtes explicitement la mise en œuvre de l'interface. Si vous faites, il est implicite en supprimant le nom de l'interface à partir de la méthode mise en place, il va fonctionner comme vous le souhaitez.

    void LOL()
{
    GlobalLOLHandler.RaiseROFLCOPTER(this);
}
public Rofl()
{
    LOL();
}

    OriginalL'auteur Isak Savo

  5. -2

    Vous n'avez pas besoin de cast. Depuis ROFL implémente ILOL vous pouvez simplement appeler this.LOL() ou même juste LOL();

    -1 Mal. MDR explicitement implémente ILOL et ne peut pas accéder à ILOL membres sans avoir accès à une instance (this coulé) de ILOL.

    OriginalL'auteur cortijon