Interior privado classes em C# - por que não são usados com mais freqüência?

Question

Eu sou relativamente novo para C# e a cada vez que eu começar a trabalhar em um projeto C# (eu só trabalhei em quase maduro projetos em C#) eu me pergunto por que não há classes internas?

Talvez eu não entenda o seu objetivo.Para mim, classes internas, pelo menos no interior privado classes -- parecer muito "interior procedimentos", de Pascal / Modula-2 / Ada :eles permitem dividir uma classe principal em partes menores a fim de facilitar a compreensão.

Exemplo :aqui está o que é ver a maioria do tempo :

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

public class ClassB
{
   public DoSomething()
   {
   }
}

Desde ClassB vai ser utilizado (pelo menos por um tempo) só por ClassA, meu palpite é que esse código poderia ser melhor expressa como a seguir :

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

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

Eu ficaria feliz em ouvir de você sobre este assunto - Estou certo?

Answer 1

As aulas aninhadas (provavelmente é melhor evitar a palavra "interior", pois as classes aninhadas em C# são um pouco diferentes das classes internas em Java) podem realmente ser muito úteis.

Um padrão que não foi mencionado é o padrão "melhor enum" - que pode ser ainda mais flexível que o de Java:

public abstract 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
        }
    }
}

Poderíamos fazer com algum suporte de linguagem para fazer parte disso automaticamente - e há muitas opções que eu não mostrei aqui, como não usar uma classe aninhada para todos os valores ou usar a mesma classe aninhada para vários valores, mas dando a eles parâmetros de construtor diferentes. Mas, basicamente, o fato de a classe aninhada chamar o construtor privado dá muito poder.

Answer 2

o Diretrizes de design da estrutura Tem as melhores regras para o uso de classes aninhadas que encontrei até agora.

Aqui está uma breve lista de resumo:

1. Use tipos aninhados quando a relação entre tipo e tipo aninhada for tão desejada como a semântica de acessibilidade para membros.

2. Fazer NÃO Use tipos públicos aninhados como uma construção de grupo lógico

3. Evite usar tipos aninhados expostos publicamente.

4. Fazer NÃO Use tipos aninhados se é provável que o tipo seja referenciado fora do tipo contendo.

5. Fazer NÃO Use tipos aninhados se precisarem ser instanciados pelo código do cliente.

6. Fazer NÃO Defina um tipo aninhado como um membro de uma interface.

Answer 3

Você deve limitar as responsabilidades de cada classe, de modo a que cada um fica simples, testável e reutilizáveis.Interior privado classes de ir contra isso.Eles contribuem para a complexidade do exterior de classe, eles não são testáveis e não são reutilizáveis.

Answer 4

Para mim, pessoalmente, crio apenas classes internas privadas se precisar criar coleções em processo de um objeto que possa exigir métodos nelas.

Caso contrário, isso pode causar confusão para outros desenvolvedores que trabalham no projeto para encontrar essas classes, pois não são muito claras quanto ao local onde estão.