membre interne dans une interface

J'ai une liste d'objets implémentant une interface, et une liste de l'interface:

public interface IAM
{
    int ID { get; set; }
    void Save();
}

public class concreteIAM : IAM
{
     public int ID { get; set; }
     internal void Save(){
     //save the object
     }

    //other staff for this particular class
}

public class MyList : List<IAM>
{
    public void Save()
    {
        foreach (IAM iam in this)
        {
            iam.Save();
        }
    }

    //other staff for this particular class
}

Le code ne compile pas car le compilateur a besoin de tous les membres interface publique.

internal void Save(){

Mais je ne veux pas permettre à l'provenant de l'extérieur de ma DLL pour enregistrer le ConcreteIAM, il ne doit être enregistré par le MyList.

Toute façon de le faire?

Mise à jour#1: Salut à tous, merci pour les réponses, mais aucune n'est exactement ce dont j'ai besoin:

L'interface doit être publique, parce que c'est la signature du client à partir de l'extérieur de la dll à utiliser, avec ID et d'autres propriétés que je n'ai pas pris la peine d'écrire dans l'exemple de garder les choses simples.

Andrew, je ne pense pas que la solution est de créer une usine pour créer un autre objet qui contiendra les IAM membres + Enregistrer. Je suis encore à penser... d'autres idées?

merci pour les réponses, mais aucune n'est exactement ce dont j'ai besoin: L'interface doit être publique, parce que c'est la signature du client à partir de l'extérieur de la dll à utiliser, avec ID et d'autres propriétés que je n'ai pas pris la peine d'écrire dans l'exemple de garder les choses simples. Andrew, je ne pense pas que la solution est de créer une usine pour créer un autre objet qui contiendra les IAM membres + Enregistrer. Je suis encore à penser... d'autres idées?
Si vous voulez garder de la méthode d'enregistrement sur le concreteAM classe votre meilleur pari est probablement pour aller avec une classe de base abstraite, avec un intérieur abstrait méthode Save comme suggéré par Nathan W.
mieux vaut tard que jamais, mais cela peut aider: stackoverflow.com/a/18944374/492

InformationsquelleAutor | 2008-12-15

c#concreteclass interface

39

Je pense que vous ne comprenez pas ce qu'est une interface pour. L'Interface est un contrat. Il précise que l'objet se comporte d'une certaine façon. Si un objet implémente une interface, cela signifie que vous pouvez compter sur elle qu'il a tout l'interface, les méthodes de mise en œuvre.

Maintenant, imaginez ce qui se passerait s'il y avait une interface comme vous demandez - public, mais avec un membre interne. Ce que cela signifierait? Un objet externe pourrait mettre en œuvre uniquement les méthodes publiques, mais pas l'intérieur. Lorsque vous recevez un tel objet externe, vous serez en mesure d'appeler seulement le public, mais pas à l'intérieur, parce que l'objet ne pouvait pas la mettre en œuvre. En d'autres termes - le contrat ne serait pas satisfaite. Pas tous les moyens seraient mis en œuvre.

Je pense que la solution dans ce cas est de diviser votre interface en deux. Une interface sera publique, et c'est ce que vos objets externes mettrait en œuvre. L'autre interface est interne et contiendra votre Save() internes et d'autres méthodes. Peut-être cette deuxième interface pourrait même hériter de la première. Vos propres objets internes serait alors de mettre en œuvre les deux interfaces. De cette façon, vous pourriez même faire la distinction entre les objets externes (ceux qui n'ont pas l'interface interne) et les objets internes.
- Ouf! quelqu'un de réellement prendre du recul et de se demander pourquoi, plutôt que d'essayer de code de tourner en rond...
- Scénario Simple: une assemblée des classes Thing1 et Thing2 qui, pour diverses raisons, ne peuvent utilement partager un type de base, mais partagent une interface IThing. Il souhaite donner à l'extérieur de code d'objets qui peut être transmis à un code qui a besoin d'un IThing, mais il veut garantir que toute IThing il reçoit va effectivement mettre en œuvre l'IThing contrat correctement, en interdisant toutes les implémentations de l'extérieur de l'assemblée. On pourrait obtenir un résultat similaire en utilisant une classe wrapper ou structure, mais le code serait plus propre si on n'a pas eu à le faire.
- Je crains que je ne peux pas penser à une façon d'atteindre cet objectif en C#. Cependant, il y a beaucoup de choses qui ne peuvent pas être réalisés en C# (ou dans toute autre langue d'ailleurs). C'est pourquoi les contrats de code existent.
- Je sais, ça fait 5 ans, mais je ressens le besoin de répondre. Ce qu'il demande, c'est équivalent à 'interne protégé abstrait". Il souffre de tous les mêmes effets secondaires (aucun). Le responsable de l'implémentation serait forcé de la mettre en œuvre. Il serait exigible uniquement à partir de l'assemblée qui possédait la définition de la méthode et de l'exécutant lui-même. Même chose, exactement. Juste, pas pris en charge.
- Une interface est une liste de public méthodes qu'une classe doit avoir. C'est son but. Il ne se soucie pas (ni ne sera jamais de soins, même dans les futures versions de .NETTE) sur private/protected/méthodes internes.
- Je suis tout à fait conscient de ce qu'est une interface EST. Ce que je veux dire c'est que ce que l'OP est de poser des questions pour ne pas avoir des effets secondaires. Il n'existe pas dans la langue, et je pense que nous savons tous cela, mais il POURRAIT exister dans la langue. Et je ne dis pas qu'il le fera. Mais il pourrait l'être.
- Alors... ce serait une interface qui est visible du grand public, mais a des membres qui sont à l'intérieur, de sorte qu'il ne peut être mis en œuvre à l'interne? Je ne suis pas sûr de ce que les implications de ce serait. Il "sent" en quelque sorte que cela pourrait causer de graves conflits dans le CLR, mais je n'en sais pas assez pour justifier cette intuition. Il serait intéressant d'entendre l'avis de quelqu'un de bien informé sur le sujet.
- Seulement à partir du cas d'utilisation point de vue de la logique de définir un contrat qui spécifie qu'une méthode existe, mais seront seulement être appelé à partir d'objets stockés dans la même assemblée. Je voudrais avoir la fonctionnalité, certainement.
- J'ai le même problème quelques années, j'ai un moteur qui nécessite des Modèles pour fournir un interne de la méthode Render (), pas une méthode publique, une méthode interne, parce que le code du jeu n'est pas responsable pour le dessin. Et pourtant, les interfaces ne fournissent pas les contrats internes. C'est une terrible lacune. Il n'y a absolument aucune raison, un contrat fourni par le moteur ne peut pas dire - " vous devez fournir un interne méthode de dessin, parce que j'ai besoin d'elle, et je comprends que vous avez personnalisé le code de dessin. Et je suis un moteur de jeu en utilisant une entité composant le système et je n'aime pas avoir trop de héritage"
- l'interface qui est visible du grand public, mais a des membres qui sont à l'intérieur, de sorte qu'il ne peut être mis en œuvre en interne?" - exactement. C'est le même que pour un non-classe scellée avec un interne constructeur: Visible, mais il ne peut être sous-classé en interne. J'ai régulièrement appel à ce modèle quand je veux que les utilisateurs de l'API avec une hiérarchie d'objets qu'ils ne peuvent pas modifier de l'extérieur (ou seulement à "ouvert" nœuds plutôt que de droit, à la classe de base). A plusieurs reprises j'ai souhaité faire quelque chose de similaire avec les interfaces.
- Donc, fondamentalement, vous voulez une interface qui peut être transmise à un code externe, mais ne peut être mis en œuvre par les classes internes. Eh bien... je peux voir l'utilisation de ce. Malheureusement, je ne suis pas assez bien versé dans les entrailles de la .NET et les décisions de conception-à-dire pourquoi il n'est pas possible actuellement. Je soupçonne qu'il ya une raison bien.
- Oui, c'est exactement ce que je veux. Je ne suis pas sûr qu'il y est une raison technique, étant donné que la même peut être fait en interne avec les constructeurs, ou avec interne des méthodes abstraites, comme décrit ci-dessus. Je suppose que c'est simplement une question de prendre des décisions à l'encontre de complexité supplémentaire dans le compilateur C# (ou même la CLI d'exécution définition des interfaces).
- Quelques suppositions: il pourrait y avoir des problèmes de compatibilité avec COM (.NET est TRÈS sympathique de COM et de beaucoup de .NET concepts de la carte directement à COM concepts) ou d'autres langues qu'ils voulaient facile interopérabilité avec d'; les interfaces et les classes peuvent être très différentes créatures du faible niveau de point de vue (MSIL) et en introduisant des modificateurs pourrait vraiment compliquer les choses; il pourrait aussi être des questions idéologiques (comme si vous définissez explicitement une interface comme un "marché public" ou quelque chose d'interne, les membres contre qui).
- Et le dernier mais non le moindre - toutes les fonctionnalités commence avec -100 points. Il ya seulement tellement de temps disponible pour le développement, et la liste est toujours beaucoup plus de temps que ce qui peut être accompli de façon réaliste. Si vous avez besoin de ramasser quelques-uns des choses qui sont les plus utiles. Peut-être que cette fonctionnalité n'a tout simplement pas faire la coupe. Heck, l'extension de propriétés sont encore plus largement demandé, et même qu'ils n'ai pas encore eu le feu vert de encore (autant que je sache).
- Votre réponse n'a rien à voir avec l'accès à cette mise en œuvre si. Comme j'ai pu juste faire une classe abstraite, plein de remplir le contrat et les différentes conditions d'accès pour le compilateur à prendre en compte. Une interface doit fonctionner de la même manière.
- Je ne suis pas sûr de ce que tu veux dire. Vous ne pouvez pas changer les modificateurs d'accès lors de la substitution.
InformationsquelleAutor Vilx-
25

Faire une autre interface qui est interne, et utiliser explicitement la mise en œuvre de la méthode.
```
internal interface InternalIAM
{
    void Save();
}

public class concreteIAM : InternalIAM
{
    void InternalIAM.Save()
    {
    }
}
```
- Merci, j'ai toujours voulu savoir comment faire pour avoir un public de classe implémente une interface interne.
- voir aussi stackoverflow.com/a/18944374/492
- Un problème avec ceci est que vous ne pouvez pas avoir des méthodes publiques qui utilisent InternalIAM comme un type de paramètre.
InformationsquelleAutor Lasse Vågsæther Karlsen

Je ne pense pas que vous devriez être à l'aide d'une interface ici, peut-être devriez-vous utiliser un résumé de la base de quelque chose comme.:

public abstract class AM
{
    public int ID { get; set; }
    internal abstract void Save();
}

public class concreteIAM : AM
{
    internal override void Save()
    {
        //Do some save stuff
    }
}

Vont encore vous permettent de faire cela:

public class AMList : List<AM>
{
    public void SaveItems()
    {
        foreach (var item in this)
        {
            item.Save();
        }
    }
}

InformationsquelleAutor Nathan W

7

Je pense que la meilleure chose à faire serait de séparer l'intérieur et des membres du public en deux interfaces. Si vous héritent de l'interface vous pouvez toujours déclarer les membres publiquement, mais la visibilité des membres internes seront dictées par la visibilité de l'interface elle-même.
```
using System;

public interface IPublic
{
    void Public();
}

internal interface IInternal : IPublic
{
    void Internal();
}

public class Concrete : IInternal
{
    public void Internal() { }

    public void Public() { }
}
```
- la visibilité des membres est dictée par la mise en oeuvre du membre. Si vous instanciez un objet en Béton vous pouvez appeler sa méthode Publique.
- c'est un bon point - j'ai imaginé une sorte de méthode qui retourne le Béton comme IPublic ainsi à masquer tous les autres membres
InformationsquelleAutor Andrew Hare
3

C'est exactement ce que je parle dans mon article Des amis et interface interne des membres à aucun coût avec le codage des interfaces.

L'essence de l'article
```
public class Internal
{
    internal Internal() { }
}

public interface IAM
{
    int ID { get; set; }
    void Save(Internal access);
}
```
À partir de maintenant on ne votre assemblée peut appeler la Save() méthode, depuis une instance de la Internal classe ne peut être créé par votre assemblée.

InformationsquelleAutor Reuven Bass
1

Si vous ne voulez pas que les appelants externes pour être en mesure d'appeler votre méthode Save (), pourquoi ne pas rendre l'ensemble concreteIAM classe interne?

Ou, si vous voulez la classe public, mais pas l'interface, faire de l'ensemble de l'interface interne. Je pense que l'interface interne peut être ajouté à un public de classe (mais je n'ai pas essayé...)

InformationsquelleAutor Brannon

Peut-être que vous voulez séparer l'enregistrement de vos articles en un autre ensemble de classes qui sont internes à votre assemblée:

internal interface IAMSaver { void Save(IAM item); }

internal class AMSaverFactory {
  IAMSaver GetSaver(Type itemType) { ... }
}

public class MyList : List<IAM>
{
  public void Save()
  {
    foreach (IAM itemin this)
    {
      IAMSaver saver = SaverFactory.GetSaver(item.GetType());
      saver.Save(item)
    }
  }
}

InformationsquelleAutor Andrew Kennan

1

Interface les membres sont censés être publics.. quoi que ce soit d'autre, et vous devriez penser si vous besoin de quelque chose d'autre. Dans ce cas, vous
- souhaitez Enregistrer pour être un membre interface
- souhaitez Enregistrer pour être autorisé uniquement via une autre classe appelée Maliste qui se trouve dans la même assemblée
- refuser d'Enregistrer d'être appelé de l'extérieur (d'autres cours à l'extérieur de l'assemblage parent)
Maintenant la conception des pensées de côté, vous pouvez le faire via l'Interface Explicite de mise en Œuvre.
```
    internal interface IPersist
    {
        void Save();
    }
    public class Concrete : IPersist
    {
        void IPersist.Save()
        {
            Console.WriteLine("Yeah!");
        }
    }

//Mylist.cs in the same assembly can still call save like
public void SaveItems()
    {
        foreach (IPersist item in this)
        {
            item.Save();
        }
    }
```
IPersist est interne, ne sont pas disponibles à l'extérieur de l'assemblage parent et depuis il est explicitement mis en œuvre, il ne peut pas être appelé sans IPersist de référence.
```
new Concrete().Save();     //doesn't compile. 'Concrete' does not contain a definition for 'Save'
```
Mise à jour De votre dernière réponse, nous avons plus de contraintes.
L'Interface doit être public, il doit contenir la méthode Save, qui ne devrait pas être accessible au public.
Je dirais de retourner à la planche à dessin... quelque chose ne semble pas juste. À mon humble avis, Vous ne pouvez pas faire cela avec une interface unique. Comment diviser en 2 interfaces, le public et l'interne?

InformationsquelleAutor Gishu

Pourquoi n'utilisez-vous pas les classes internes de contrôle de l'accessibilité de vos méthodes?

Exemple:

Votre assemblée primaire

public abstract class Item
{
    public int ID { get; set; }
    protected abstract void Save();

    public class ItemCollection : List<Item>
    {
        public void Save()
        {
            foreach (Item item in this) item.Save();
        }
    }
}

Secondaire de l'assemblée

public sealed class NiceItem : Item
{
    protected override void Save()
    {
        //do something
    }
}

De ce modèle permet de mettre en œuvre Save() méthode dans d'autres assemblées, mais seulement ItemCollection qui est intérieur de la classe de Item pouvez l'appeler. Brillant, n'est-ce pas?

InformationsquelleAutor lubos hasko

Aller avec deux interfaces:

public interface IAM
{
        int ID { get; set; }
}


internal interface IAMSavable
{
        void Save();
}

public class concreteIAM : IAM, IAMSavable
{
         public int ID{get;set;}
         public void IAMSavable.Save(){
         //save the object
         }

        //other staff for this particular class
}

public class MyList : List<IAM>
{
        public void Save()
        {
                foreach (IAM iam in this)
                {
                        ((IAMSavable)iam).Save();
                }
        }

        //other staff for this particular class
}

La mise en œuvre de la Save() doit être explicite pour empêcher les clients de l'appeler.

InformationsquelleAutor MZywitza

J'ai eu la même situation et pensé que cela pourrait aider. (pas sûr si cela n'est pas nécessaire à ce moment ou pas)

C'est une pièce de théâtre cas pour moi: dans le cas où supposons qu'il y est une interface qui a une API qui est interne à la DLL et certaines API peut être accessible depuis l'extérieur de la DLL. Depuis l'interface est une classe abstraite, au lieu de le définir comme une interface, vous pouvez définir une classe abstraite.

using System.Collections.Generic;

public abstract class IAM
{
    int ID { get; set; }
    internal abstract void Save();
}

public class concreteIAM : IAM
{
    public int ID { get; set; }
    internal override void Save()
    {
        //save the object
    }

    //other staff for this particular class
}

public class MyList : List<IAM>
{
     internal void Save()
    {
        foreach (IAM iam in this)
        {
            iam.Save();
        }
    }

    //other staff for this particular class
}

InformationsquelleAutor Rishi Prasad

-2

Je me demandais sur la même question ici,
et je suis tombé sur cette question...

Que je pensais sur ce, j'ai compris je n'ai pas besoin interne méthode dans l'Interface en premier lieu.

Je peux y accéder par le biais de ma Classe de Béton,
et de laisser le Contrat pour le code Côté.

Dans votre exemple:

    public interface IAM
    {
            int ID { get; set; }
    }

    public class concreteIAM : IAM
    {
             public int ID{get;set;}
             internal void Save(){
             //save the object
             }

            //other staff for this particular class
    }

    public class MyList : List<IAM>
    {
            public void Save()
            {
                    foreach (concreteIAM iam in this)
                    {
                            iam.Save();
                    }
            }
            //other staff for this particular class
    }

-1, les résultats dans une complication de l'erreur". concreteIAM' n'implémente pas l'interface de membre d'IAM.Save()'
Chaque fois que quelqu'un a à dire 'espère que cette aide", il n'est généralement pas le cas. Comme ici.
par demande populaire, fixe l'exemple... l'interface n'ont jamais définir Enregistrer en premier lieu

InformationsquelleAutor Tomer W

Vous devez vous connecter pour publier un commentaire.