Вложенные классы: полезный инструмент или нарушение инкапсуляции?

Таким образом, я все еще нахожусь на заборе относительно того, должен ли я использовать это или нет.

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

В предыдущих проектах Java / Swing я до некоторой степени использовал вложенные классы, однако теперь я перешел в другие проекты на C # и избегаю их использования.

Как вы относитесь к вложенным классам?

Ну, и проще говоря: вложенные классы не нарушают инкапсуляцию и, в общем, языковые функции не нарушают принципы программирования. Программисты нарушают принципы программирования.

Как ни странно, вложенные классы увеличивают инкапсуляцию :

Увеличенная инкапсуляция. Рассмотрим два класса верхнего уровня, A и B, где B необходим доступ к членам A, которые в противном случае были бы объявлены закрытыми. Скрывая класс B в классе A, члены A могут быть объявлены частными, и B может получить к ним доступ. Кроме того, сам B может быть скрыт от внешнего мира.

В этом есть доля правды.

Обычно B является результатом применения SRP к A. Сам B, тем не менее, потенциально нарушает многие принципы, особенно, если все, что он делает, - это возиться с частными членами A: D

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

Мы используем вложенные классы все время. Во многих ситуациях бизнес-программное обеспечение / процессы имеют вложенные бизнес-объекты. Мы все видели пример объекта Order, который имеет вложенную коллекцию OrderItems.

Суть в том, что это облегчает чтение / написание кода и редко бывает, когда вам нужен ваш класс Order и вам не нужно знать о OrderItems.

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

Однако, если ваш проект имеет заданную область действия и инкапсулирует класс (такой как класс Node или какой-либо объект, который используется для прохождения структуры данных определенного класса), я не вижу вреда.

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

(В C #) Обычно я бы их избегал, хотя это может зависеть от цели этого класса.

Я бы никогда не использовал их для какого-либо класса модели предметной области, который просто не имеет смысла для меня.

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

Единственный раз, когда я использую их сейчас, это для странной маленькой уловки кодирования, где использование другого небольшого класса облегчает реализацию определенного класса или реализацию интерфейса, который на самом деле является просто шаблоном уведомления о событии (где внутренний класс реализует интерфейс и просто передает контроль над внешним классом).