9
votes

Existe-t-il un moyen de limiter l'accès à une méthode publique pour seulement une classe spécifique en C #?

J'ai une classe A avec une méthode publique en C #. Je veux permettre l'accès à cette méthode à la classe B. Est-ce possible?

Mise à jour forte>: p>

C'est ce que j'aimerais faire: P>

var prod = Repository.Get<Product>(id);
prod.SetInactive();
prod.Category.ProcessInactiveProduct();


2 commentaires

+1 question très intéressante.


Si vous voulez seulement avoir accès par la classe B - alors ce n'est pas une méthode «publique».


5 Réponses :


3
votes

Vous pouvez si vous faites de la classe a une classe privée et imbriquée dans la classe B : xxx

seulement B < / code> sera en mesure de voir a et il est membre dans cet exemple.

Vous pouvez également nier B intérieur A :: xxx

Dans ce cas, tout le monde peut voir à la fois A et B mais uniquement B peut voir a.foo .


2 commentaires

Merci, mais ce sont des classes séparées (non imbriquées). J'aimerais cacher une méthode de la classe A, mais le montrer (le permettez-la) à une certaine classe (classe B). A et B ne sont pas imbriqués.


Sans nidifier les types, vous ne pourrez pas faire cela à l'aide de constructions de langue par défaut. Vous devrez peut-être envisager une approche basée sur la sécurité (autoriser uniquement l'accès si un type "authentifie") mais je pense que votre besoin de ceci peut trahir une faille dans votre conception. Quelle est la plus grande image? Peut-être que si vous éditez votre message avec plus de détails, je peux vous aider à trouver une solution :)



19
votes

Placez les deux classes dans un assemblage séparé et faites la méthode interne.


2 commentaires

+1 haha! Bonne réponse! J'ai peut-être trop pensé ma réponse un peu :)


(Commentaire supprimé ... Je le lis comme des assemblages distincts, comme au pluriel)



0
votes

Il n'y a pas de réponse hors de la boîte pour votre question.

S'ils sont déjà dans le même assemblage, pourquoi ne pas rendre la méthode interne scopée à la place?

S'ils sont dans des assemblages différents, vous pouvez utiliser " Friend "Syntaxe qui couvre toutes les méthodes internes.

Probablement votre meilleure solution consiste à limiter l'accès aux méthodes publiques à un assemblage spécifique (IES). Ce qui signifie que quelqu'un ne peut pas simplement écrire un nouvel assemblage et aller de l'avant un appel vos méthodes publiques. Étant donné que vous semblez avoir un modèle de domaine, on dirait que vous devez autoriser cette méthode appelée d'autres objets de domaine, mais peut-être pas de la logique commerciale. Cela peut être atteint en attribuant un nom fort unique aux DLL de modèle de domaine.

Vous pouvez limiter l'accès à une méthode publique uniquement pour permettre d'appeler par des méthodes dans des assemblages satisfaisant une clé publique donnée. Voir msdn StrongNameDidentitypermission


0 commentaires

0
votes

Vous pouvez utiliser un type de motif d'observateur, où la catégorie enregistre un intérêt particulier pour des événements particuliers sur le produit (peut-être un événement produit-actif?) puis gère la logique de manière appropriée. Ce modèle basé sur des événements est très courant et réduit considérablement le couplage. La catégorie est finalement responsable de son propre État et ne s'appuie pas sur le produit en sachant quelque chose sur ce qui le contient afin de garder l'état de la catégorie intact. Le produit dit simplement aux clients intéressés quand les choses se sont arrivées.

Une autre option consiste à refacturer votre classe de catégorie afin qu'elle contienne ou que celle-ci soit contenue par certains objets de catégorieProductsServices qui encapsule les méthodes nécessaires à un produit à effectuer sur sa catégorie contenant. Dans le contexte qui crée les catégories et les produits, passez l'instance de cet objet de catégorieProductservices au produit plutôt que dans la catégorie complète. Cette conception conserve l'interface publique, mais empêche votre client d'accéder aux services, car ils ne peuvent pas récupérer une instance. Il dépose également le couplage serré de produits à la classe de catégorie, en limitant uniquement les services que les produits doivent être conscients. Cela laisse le produit en charge de l'état, mais au moins limite ce qu'il faut savoir / faire.


0 commentaires

2
votes

Vous pouvez limiter la méthode / l'accès de la classe de cette manière:

[StrongNameIdentityPermissionAttribute(SecurityAction.Demand, PublicKey="…hex…", Name="App1", Version="0.0.0.0")]
public class Class1 { } 


0 commentaires