Используя Внутренние классы в C#

Как правило, внутренние классы должны быть приватными и использоваться только тем классом, который их содержит. Если их внутренние классы очень велики, это говорит о том, что они должны быть их собственными классами.

Обычно, когда у вас большой внутренний класс, это потому, что внутренний класс тесно связан с содержащим его классом и нуждается в доступе к его закрытым методам.

Здесь приведен практический пример вложенного класса, который может дать вам представление об их использовании (добавлен некоторый модульный тест)

namespace CoreLib.Helpers
{
    using System;
    using System.Security.Cryptography;

    public static class Rnd
    {
        private static readonly Random _random = new Random();

        public static Random Generator { get { return _random; } }

        static Rnd()
        {
        }

        public static class Crypto
        {
            private static readonly RandomNumberGenerator _highRandom = RandomNumberGenerator.Create();

            public static RandomNumberGenerator Generator { get { return _highRandom; } }

            static Crypto()
            {
            }

        }

        public static UInt32 Next(this RandomNumberGenerator value)
        {
            var bytes = new byte[4];
            value.GetBytes(bytes);

            return BitConverter.ToUInt32(bytes, 0);
        }
    }
}

[TestMethod]
public void Rnd_OnGenerator_UniqueRandomSequence()
{
    var rdn1 = Rnd.Generator;
    var rdn2 = Rnd.Generator;
    var list = new List<Int32>();
    var tasks = new Task[10];
    for (var i = 0; i < 10; i++)
    {
        tasks[i] = Task.Factory.StartNew((() =>
        {
            for (var k = 0; k < 1000; k++)
            {
                lock (list)
                {
                    list.Add(Rnd.Generator.Next(Int32.MinValue, Int32.MaxValue));
                }
            }
        }));
    }
    Task.WaitAll(tasks);
    var distinct = list.Distinct().ToList();
    Assert.AreSame(rdn1, rdn2);
    Assert.AreEqual(10000, list.Count);
    Assert.AreEqual(list.Count, distinct.Count);
}

[TestMethod]
public void Rnd_OnCryptoGenerator_UniqueRandomSequence()
{
    var rdn1 = Rnd.Crypto.Generator;
    var rdn2 = Rnd.Crypto.Generator;
    var list = new ConcurrentQueue<UInt32>();
    var tasks = new Task[10];
    for (var i = 0; i < 10; i++)
    {
        tasks[i] = Task.Factory.StartNew((() =>
        {
            for (var k = 0; k < 1000; k++)
            {
                    list.Enqueue(Rnd.Crypto.Generator.Next());
            }
        }));
    }
    Task.WaitAll(tasks);
    var distinct = list.Distinct().ToList();
    Assert.AreSame(rdn1, rdn2);
    Assert.AreEqual(10000, list.Count);
    Assert.AreEqual(list.Count, distinct.Count);
}

Мне лично нравится иметь один класс на файл и внутренние классы как часть этого файла. Я считаю, что внутренние классы, как правило (почти всегда), должны быть частными и являются деталями реализации класса. Хранение их в отдельном файле приводит к путанице, [IM]. Использование областей кода для обтекания внутренних классов и скрытия их данных в данном случае хорошо работает и не позволяет работать с файлом. Области кода сохраняют внутренний класс «скрытым», и, поскольку это частная деталь реализации, это меня устраивает.

Относительно только того, как структурировать такого зверя ...

Вы можете использовать частичные классы, чтобы разделить основной класс и вложенные классы. Когда вы делаете это, вам советуют правильно присваивать имена файлам, чтобы было понятно, что происходит.

// main class in file Outer.cs
namespace Demo
{
  public partial class Outer
  {
     // Outer class
  }
}

// nested class in file Outer.Nested1.cs
namespace Demo
{
  public partial class Outer
  {
    private class Nested1
    {
      // Nested1 details
    }
  }
}

Во многом таким же образом вы часто видите (явные) интерфейсы в их собственном файле. например, Outer.ISomeInterface.cs , а не редактор по умолчанию #region их.

Структура файлов вашего проекта начинает выглядеть как

   /Project/Demo/ISomeInterface.cs
   /Project/Demo/Outer.cs
   /Project/Demo/Outer.Nested1.cs
   /Project/Demo/Outer.ISomeInterface.cs

Обычно, когда мы делаем это для вариации шаблона Builder.

Я лично использую внутренние классы для инкапсуляции некоторых концепций и операций, используемых только внутри класса. Таким образом, я не загрязняю непубличный API этого класса и сохраняю API чистым и компактным.

Вы можете воспользоваться частичными классами, чтобы переместить определение этих внутренних классов в другой файл для лучшей организации. VS автоматически не группирует частичные файлы классов для вас, за исключением некоторых шаблонизированных элементов, таких как ASP.NET, формы WinForm и т. Д. Вам нужно будет отредактировать файл проекта и внести в него некоторые изменения. Вы можете посмотреть на одну из существующих группировок, чтобы увидеть, как это делается. Я полагаю, что есть некоторые макросы, которые позволяют группировать файлы частичных классов в обозревателе решений.

I don't have the book to hand, but the Framework Design Guidelines suggests using public inner classes as long as clients don't have to refer to the class name. private inner classes are fine: nobody's going to notice these.

Bad: ListView.ListViewItemCollection collection = new ListView.ListViewItemCollection();

Good: listView.Items.Add(...);

Regarding your large class: it's generally worthwhile splitting something like this into smaller classes, each with one specific piece of functionality. It's difficult to break it up initially, but I predict it'll make your life easier later on...

Я думаю, что это довольно субъективно, но я, вероятно, разделил бы их на отдельные файлы кода, сделав частичный класс "host".

Поступая таким образом, вы можете получить еще больше обзор, отредактировав файл проекта , чтобы группы файлов были такими же, как классы конструктора в Windows Forms. Думаю, я видел надстройку Visual Studio, которая делает это автоматически за вас, но не помню где.

РЕДАКТИРОВАТЬ:
Поразмыслив, я нашел надстройку Visual Studio для этого под названием VSCommands