[C#] C'est privé c'est public, c'est des copains

Bon!

J’ai des problèmes de droit dans mes fonctions/classes.

J’ai une classe A. Cette classe A contient une ArrayList de classe B. Cette même classe A utilise certaines fonction de la classe B (des accesseurs, des propriétés) qui sont en public.

Jusque là, pas de problème. Maintenant la ou ca se complique c’est que c’est une classe en middleware (donc sujette a être intégré dans un autre programme) et je ne veux pas que l’utilisateur puisse accéder a certaines fonctions de ma classe B.

Si je mets les fonctions en private, la classe A ne peut plus les utiliser. Si je les mets en public, tout le monde peut les utiliser. En Visual Basic 6, il existait le mot clef “Friend” qui permettait, il me semble, de faire ce genre de choses. Existe t’il l’équivalent en C#? Si oui, comment ca s’appelle? Et aussi, comment ca s’utilise?

Ps: la classe B n’est pas dérivée de la classe A, sinon j’aurais mis en protected.

L’internal ne pourrait pas convenir ? Si classe A et B sont destinés à être mis dans une librairie, et la librairie utilisée par ton appli, c’est le moyen logique pour masquer les méthodes réservées pour ta tambouille interne.

Je confirmes, internal est ton ami, abuses-en :P.

De ce que j’ai vu, le mécanisme le plus proche est d’utiliser le mot clé internal lors de la déclaration de la classe ou du membres.

Je serais intéressé de connaitre la solution précise :stuck_out_tongue:

Yup, internal, mais sans en abuser, c’est pas un superbe design en general des trucs internal de partout.

[quote name=‹ TwinSidE › date=’ 17 May 2005, 09:48’]Je serais intéressé de connaitre la solution précise :stuck_out_tongue:
[right][post=« 359757 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Hu ?

Ben tu as plusieurs mots clé pour définir l’accessibilité de ta classe :
public, private, protected, internal, protected internal.

Les 3 premiers sont évidents, les 2 derniers sont un peu plus spécifiques.

internal définit qu’une classe ou qu’un membre ne sera visible et utilisable que par le code de la même assembly.

protected internal correspond à un ou inclusif entre protected et internal.

MSDN est ton ami : http://msdn.microsoft.com/library/default…pspec_3_5_1.asp

Edit : sinon pareil que miguel, les internal, il faut s’en méfier : ca masque souvent des problèmes d’archi, donc à utiliser avec parcimonie.

Et la question piege :stuck_out_tongue: les protected internal sont ils protected ET internal ou protected OU internal? (genre on peut en heriter/overrider que dans des classes de la meme assembly, ou on peut les overrider OU y acceder depuis le reste de l’assembly). Question bonus, le MSIL supporte il la distinction, meme si C# n’a qu’une seule definition?

Edit: haha j’avais pas vu que Styx31 avait deja repondu a la premiere question

Bon, ça m’a fait chercher un peu…

[quote]A type scopes all of its members, and it also specifies the accessibility rules for its members. Except where noted, accessibility is decided based only on the statically visible type of the member being referenced and the type and assembly that is making the reference. The CTS supports seven different rules for accessibility:
• Compiler-Controlled – accessible only through use of a definition, not a reference, hence only accessible from within a single compilation unit and under the control of the compiler.
• Private – accessible only to referents in the implementation of the exact type that defines the member.
• Family – accessible to referents that support the same type, i.e. an exact type and all of the types that inherit from it.  For verifiable code (see Section 7.8), there is an additional requirement that may require a runtime check: the reference shall be made through an item whose exact type supports the exact type of the referent.  That is, the item whose member is being accessed shall inherit from the type performing the access.

  • Assembly – accessible only to referents in the same assembly that contains the implementation of the type.
    [b]* Family-and-Assembly – accessible only to referents that qualify for both Family and Assembly access.
  • Family-or-Assembly – accessible only to referents that qualify for either Family or Assembly access.[/b]
  • Public – accessible to all referents.
    In general, a member of a type can have any one of these accessibility rules assigned to it. There are two exceptions, however:
  1. Members defined by an interface shall be public.
  2. When a type defines a virtual method that overrides an inherited definition, the accessibility shall either be identical in the two definitions or the overriding definition shall permit more access than the original definition.  For example, it is possible to override an assembly virtual method with a new implementation that is public virtual, but not with one that is family virtual.  In the case of overriding a definition derived from another assembly, it is not considered restricting access if the base definition has Family-or-Assembly access and the override has only family access.[/quote]
    Donc ouaip, le CLI gère les deux cas.

Ils sont trop forts sur ce site :stuck_out_tongue: meme pas drole…