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

11

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

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

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

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

Брайан Харрингтон
источник
Как именно вложенные классы являются нарушением инкапсуляции? Во всяком случае, они являются более инкапсулированными, поскольку они «инкапсулированы» внутри другого класса и, при желании, могут быть сделаны частными.
Стивен Джеурис

Ответы:

8

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

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

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

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

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

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

back2dos
источник
5

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

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

Вальтер
источник
1

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

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

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

Шова
источник
0

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

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

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

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

Энди Лоури
источник