Класс, объявленный в другом классе в C#

Это имеет последствия полномочий. "Класс y" верхнего уровня был бы "внутренним" - однако, здесь "y" является частным к "x". Этот подход полезен для деталей реализации (например, строки кэша и т.д.). Аналогично, y имеет доступ ко всему частному состоянию x.

Существуют также последствия с дженериками; x<T>.y универсально "T", наследованный от внешнего класса. Вы видите это здесь, где Bar имеет использование в полной мере T - и обратите внимание что любые статические поля Bar ограничены по объему на -T.

class Foo<T> {
    void Test(T value) {
        Bar bar = new Bar();
        bar.Value = value;
    }
    class Bar {
        public T Value { get; set; }
    }
}

Часто люди неправильно думают, что они должны определить Bar как Bar<T> - это теперь (эффективно) вдвойне универсально - т.е. Foo<TOld, T> - где TOld (теперь недоступен) T от Foo<T>. Не делайте этого! Или если Вы хотите, чтобы это было вдвойне универсально, выберите различные имена. К счастью, компилятор предупреждает Вас об этом...

Этот код прекрасен по точной причине, что Вы дали - "класс y, только когда-либо используется в классе x". Это - вложенные типы, и одна из инструкций для использования их - то, что вложенные типы должны быть сильно связаны к их объявлению типа и не должны быть полезными как тип общего назначения. Тем путем вложенный класс недоступен другим классам, но все еще позволяет Вам следовать за объектно-ориентированными принципами.

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

Если бы Y используется только в X и никогда не будет использоваться за пределами X, я сказал бы, сохраняют его там

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

Позвольте мне дать Вам пример использования вложенных классов, которые могли бы разъяснить, когда этот вид архитектуры является соответствующим. Я недавно должен был генерировать HTML-таблицу путем получения по запросу выбранных столбцов из таблицы данных и "поворота" их так, чтобы строки стали столбцами и наоборот. В моем случае было две существенных операции: вертясь данные и генерируя некоторый довольно комплексный выход (я только показывал данные: каждый столбец данных / строка таблицы подвергся операциям для извлечения заголовка, генерация тегов изображения, ссылки установки, и т.д. таким образом с помощью Центра SQL не были действительно правильными ни один).

После начальной попытки создать один класс, чтобы сделать все это, я распознал, что так большая часть данных/методов попала в три отличных раздела: обработка заголовка, обработка строки и поворот. Таким образом я решил, что лучший подход должен будет инкапсулировать логику для "заголовка" и "строки" в отдельные, вложенные классы. Это позволило мне разделять данные, сохраненные каждой строкой и программировать операции центра очень чисто (называющий отдельный объект строки для каждого столбца в Вашей таблице данных). В конце операций центра я генерировал произведенный путем вызова объекта заголовка и затем каждого объекта строки в свою очередь для генерации его вывода назад к основному классу.

Отдельные классы не были соответствующими потому что A) вложенным классам действительно были нужны некоторые данные из мастер-класса и B) обработка была очень конкретна и не полезна в другом месте. Просто программирование одного большого класса было просто более грязным из-за условий окружения беспорядка, таких как "столбец" и "строка", которая отличалась в зависимости от того, говорили ли Вы о выводе данных или выводе HTML. Кроме того, это было необычной работой, в которой я генерировал HTML в своем бизнес-классе, таким образом, я хотел разделить чистую бизнес-логику от поколения UI. В конце вложенные классы обеспечили идеальный баланс, затем, инкапсуляции и совместного использования данных.

Вы могли все еще осуществить рефакторинг свой класс y в другой файл, но использовать parial класс. Преимущество этого - то, что Вы все еще имеете один класс на файл и не имеете стычек рефакторинга перемещения объявления за пределами класса x.

например, у Вас мог быть файл кода: x.y.cs, который посмотрел бы что-то как

partial class X
{
    class Y
    {
        //implementation goes here
    }
}