Приватні внутрішні класи в C # - чому їх не використовують частіше?

Я відносно новачок у C #, і кожного разу, коли я починаю працювати над проектом C # (я працював лише над майже зрілими проектами в C #), мені цікаво, чому немає внутрішніх класів?

Можливо, я не розумію їх мети. Для мене внутрішні класи - принаймні приватні внутрішні класи - дуже схожі на "внутрішні процедури" в Pascal / Modula-2 / Ada: вони дозволяють розбити основний клас на менші частини, щоб полегшити розуміння.

Приклад: ось що бачимо більшу частину часу:

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

public class ClassB
{
   public DoSomething()
   {
   }
}

Оскільки ClassB буде використовуватися (принаймні на деякий час) лише ClassA, я гадаю, що цей код буде краще виразити наступним чином:

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

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

Я був би радий почути від вас на цю тему - я маю рацію?

Вкладені класи (мабуть, краще уникати слова "внутрішній", оскільки вкладені класи в C # дещо відрізняються від внутрішніх класів у Java) дійсно можуть бути дуже корисними.

Одним із шаблонів, про який не згадувалося, є шаблон "кращого переліку", який може бути навіть більш гнучким, ніж шаблон у 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
        }
    }
}

Ми могли б зробити з якоюсь мовною підтримкою, щоб зробити щось із цього автоматично - і є багато варіантів, які я тут не показував, наприклад, насправді не використовувати вкладений клас для всіх значень, або використовувати той самий вкладений клас для кількох значень, але надаючи їм різні параметри конструктора. Але в основному той факт, що вкладений клас може викликати приватний конструктор, дає велику силу.

Design Guidelines Framework має кращі правила для використання вкладених класів , які я знайшов на сьогоднішній день.

Ось короткий підсумковий список:

1. Використовуйте вкладені типи, коли взаємозв'язок між типом і вкладеним типом є такою, як бажана семантика доступності членів.

2. Як НЕ використовувати загальнодоступні вкладені типи в якості логічної конструкції групи

3. Уникайте використання загальнодоступних вкладених типів.

4. Як НЕ використовувати вкладені типи , якщо тип може посилатися поза містить типу.

5. Як НЕ використовувати вкладені типи , якщо вони повинні бути створені з допомогою клієнтського коду.

6. Як НЕ визначати вкладений тип в якості члена інтерфейсу.

Ви повинні обмежити обов'язки кожного класу, щоб кожен з них залишався простим, перевіряним та багаторазовим . Приватні внутрішні класи суперечать цьому. Вони сприяють складності зовнішнього класу, їх не можна перевірити і не можна повторно використовувати.

Для мене особисто я створюю приватні внутрішні класи, лише якщо мені потрібно створити в процесі колекції об'єкта, які можуть потребувати методів на них.

В іншому випадку це може спричинити плутанину для інших розробників, які працюють над проектом, насправді знайти ці класи, оскільки вони не дуже чітко знають, де вони знаходяться.