Les classes internes privées en C # - pourquoi ne sont-elles pas utilisées plus souvent?

Question

Je suis relativement nouveau à C# et chaque fois que je commence à travailler sur un projet C# (je n'ai travaillé que sur près de maturité des projets en C#), je me demande pourquoi il n'y a pas de classes internes?

Peut-être que je ne comprends pas leur but. Pour moi, les classes internes -- au moins privée les classes internes -- ressemblent beaucoup à des "procédures intérieures" de Pascal / Modula-2 / Ada : ils permettent de décomposer une classe principale en petites parties afin de faciliter la compréhension.

Exemple : voici ce que c'est de voir la plupart du temps :

public class ClassA
{
   public MethodA()
   {
      <some code>
      myObjectClassB.DoSomething(); // ClassB is only used by ClassA
      <some code>
   }
}

public class ClassB
{
   public DoSomething()
   {
   }
}

Depuis ClassB sera utilisé (au moins pour un temps) que par ClassA, je suppose que ce code serait mieux exprimée comme suit :

   public class ClassA
   {
      public MethodA()
      {
         <some code>
         myObjectClassB.DoSomething(); // Class B is only used by ClassM
         <some code>
      }

      private class ClassB
      {
         public DoSomething()
         {
         }
      }
   }

Je serais heureux de vous entendre sur ce sujet - ai-je le droit?

Merci à l'avance!

Answer 1

Classes imbriquées (probablement la meilleure pour éviter le mot "intérieur" que les classes imbriquées en C# sont un peu différentes à l'intérieur des classes en Java) peut en effet être très utile.

Un modèle qui n'a pas été évoqué, c'est le "mieux " enum" - qui peut être plus souple que celle en Java:

public class MyCleverEnum
{
    public static readonly MyCleverEnum First = new FirstCleverEnum();
    public static readonly MyCleverEnum Second = new SecondCleverEnum();

    // Can only be called by this type *and nested types*
    private MyCleverEnum()
    {
    }

    public abstract void SomeMethod();
    public abstract void AnotherMethod();

    private class FirstCleverEnum : MyCleverEnum
    {
        public override void SomeMethod()
        {
             // First-specific behaviour here
        }

        public override void AnotherMethod()
        {
             // First-specific behaviour here
        }
    }

    private class SecondCleverEnum : MyCleverEnum
    {
        public override void SomeMethod()
        {
             // Second-specific behaviour here
        }

        public override void AnotherMethod()
        {
             // Second-specific behaviour here
        }
    }
}

On pourrait faire avec un peu de support de langue pour faire cela automatiquement et il ya beaucoup d'options que je n'ai pas montré ici, comme pas réellement à l'aide d'une classe imbriquée pour toutes les valeurs, ou à l'aide de la même classe imbriquée pour plusieurs valeurs, mais en leur donnant différents paramètres du constructeur. Mais, fondamentalement, le fait que la classe imbriquée peut appeler le constructeur privé donne beaucoup de puissance.

Answer 2

Le Cadre des lignes Directrices de Conception a les meilleures règles pour l'utilisation de classes imbriquées que j'ai trouvé à ce jour.

Voici un bref résumé de la liste

1) utilisez les types imbriqués lorsque la relation entre le type et imbriqués de type est-ce le membre de l'accessibilité sémantique est souhaitée.

2) N'utilisez PAS de public les types imbriqués comme un groupe logique de construire

3) Éviter d'utiliser des exposés publiquement les types imbriqués.

4) Ne PAS utiliser les types imbriqués si le type est susceptible d'être référencé à l'extérieur du contenant de type.

5) N'utilisez PAS les types imbriqués si ils ont besoin d'être instancié par le code du client.

6) Ne définit PAS un type imbriqué en tant que membre d'une interface.

Answer 3

Vous devez limiter les responsabilités de chaque classe afin que chacune reste simple, testable et réutilisable . Les classes internes privées vont à l'encontre de cela. Ils contribuent à la complexité de la classe externe, ils ne sont pas testables et ils ne sont pas réutilisables.

Answer 4

Personnellement, je ne crée des classes internes privées que si j'ai besoin de créer des collections in-process d'un objet pouvant nécessiter des méthodes.

Sinon, les autres développeurs travaillant sur le projet pourraient trouver ces classes, car elles ne sont pas très claires quant à leur emplacement.