2009-08-24 6 views
1

J'ai posé cette question à plusieurs personnes et jusqu'à présent, je n'ai pas de réponse.C# classe/namespace Accès

ASP.NET C#

arborescence du projet (fichiers et dossiers):

> (ROOT) 
> 
> Class MyAccess (namespace myproject.core) 
> 
> (Directory John) 
------> Class MyJohn   (namespace myproject.core.John) 
------> Class JohnSecret  (namespace myproject.core.John) 
------> Class OtherJohnSecret (namespace myproject.core.John) 
> 
> (Directory Paul) 
------> Class MyPaul   (namespace myproject.core.Paul) 
------> Class PaulSecret  (namespace myproject.core.Paul) 

Comment puis-je utiliser (public, privé, protégé, interne) ????? d'avoir ce comportement qui:

  • MyJohn de classe voit et peut créer des objets à partir de toutes les classes dans le dossier John (tous ses secrets)
  • MyPaul de classe ont le même comportement, mais l'intérieur du dossier Paul
  • Tous ces secrets NE PEUT PAS être utilisé en dehors de ce dossier.

Exemples:

  • MyPaul peut utiliser tous ses secrets, et il peut communiquer avec les classes MyAccess et MyJohn.
  • MyPaul, MyJohn, MyAccess seront publics ou internes
  • MyAccess ne peut pas utiliser PaulSecret.

Solutions que je n'aime pas:

  • Solution BAD 1

Faire secrets John comme protégés et le patrimoine d'une MyJohn

Exemple:

> protected JohnSecret 
> internal MyJohn:JohnSecret 

mauvais parce que si j'ai 100 secrets de classe je besoin d'avoir quelque chose comme:

> internal MyJohn:JohnSecret1, JohnSecret2,....,JohnSecret100 
  • Solution BAD 2

ont des classes à l'intérieur des classes:

> internal class MyJohn { 
> 
>  internal string DoSomething(){} 
>   
>  private class JohnSecret{} 
>  private class JohnSecret2{} 
>  private class JohnSecret3{} 
> 
> } 

Ce n'est pas bon parce que, encore une fois, si j'ai 100 secrets je vais avoir un énorme fichier, je ne peux pas partager ce code dans différents fichiers de code source.


Quelqu'un peut-il donner une bonne solution?

J'apprécie :)

Merci beaucoup.

+0

Pourquoi avez-vous besoin de tant de classes secrètes? – Jared314

+0

Si vous avez des situations si complexes avec des modificateurs d'accès, je suppose qu'il doit y avoir quelque chose d'autre qui ne va pas dans votre situation. – Juri

+0

Cette question est venue quand nous avons du code qui sera développé par une équipe (plusieurs personnes codant -> contrôle CVS) et parfois avec IntelliSense de Visual Studio nous pouvons accéder à une classe (dans un autre répertoire de code) qui ne devrait pas être utilisée directement . C'est pourquoi j'ai demandé comment pouvons-nous éviter cela. – Dryadwoods

Répondre

3

Vous devriez aller avec la deuxième solution que vous proposez.Pour les besoins de visibilité que vous avez, il est le plus approprié pour JohnSecret, OtherJohnSecret, et. Al. à définir dans la classe MyJohn.

Si vous souhaitez diviser le fichier de classe en plusieurs fichiers, vous pouvez utiliser partial classes pour y parvenir tout en conservant les exigences de visibilité que vous avez.

Par exemple:

> (Directory John) 
> File "MyJohn.cs" 
public partial class MyJohn 
{ 
} 

> File "JohnSecret.cs" 
public partial class MyJohn 
{ 
    private class JohnSecret 
    { 
    } 
} 

> File "OtherJohnSecret.cs" 
public partial class MyJohn 
{ 
    private class OtherJohnSecret 
    { 
    } 
} 
1

C# a l'accès suivant.

  • public - tout le monde peut le voir
  • private - seules choses à l'intérieur de la classe peut voir
  • protected - seules choses à l'intérieur de la classe, ou à l'intérieur des classes dérivées peuvent voir
  • internal - seules choses à l'intérieur de l'assemblage (dll ou exe) peut le voir
  • protected internal - seules les choses à l'intérieur de la classe ou les classes dérivées peuvent le voir, et seulement si elles sont dans le même assemblage

Vous avez seulement 2 options:

  • Comme Neil mentioned, vous pouvez utiliser internal et diviser votre code en 2 ensembles - un pour John et un pour Paul.
  • Comme vous l'avez déjà mentionné, vous pouvez utiliser private et imbriquer toutes les classes JohnSecret dans la classe externe John. paracycle's tip of using partial classes rend cela raisonnablement agréable.

Remarque: pour créer plusieurs assemblages, vous devez créer plusieurs projets dans Visual Studio. D'un point de vue pragmatique, est-ce vraiment important si les répertoires sont séparés les uns des autres comme ça? L'utilisation de modificateurs d'accès ne présente aucun avantage sur le plan de la sécurité, car tout le monde peut toujours utiliser la réflexion pour appeler facilement vos méthodes privées/internes.

Le principal avantage que cela vous procure est de garder le fouillis hors de votre chemin lors du codage, mais vous les avez déjà mis dans des espaces de noms différents, ce qui devrait aider avec encombrement de toute façon.

+0

J'ai testé les classes partielles comme le dit "paracycle" et ça marche bien. A propos de l'aspect de la réflexion dont vous avez parlé: J'ai utilisé l'outil "Red Gate's .NET Reflector" et oui, je peux voir toutes mes classes privées et mon core. Je suis également capable de démonter. et je peux voir le code ....: S Cela m'a montré qu'il n'y a pas un moyen de protéger notre code? Comment puis-je vendre un programme et ne pas autoriser un smartguy à cloner mon code? – Dryadwoods

+1

En fait, 'protected internal' est' protected' * ou * 'internal', il est donc visible pour tout dans le même assembly, la classe elle-même et ses classes dérivées, quel que soit l'assemblage dans lequel elles se trouvent. –