Вкладені класи: Корисний інструмент чи порушення інкапсуляції?

Тож я все ще на паркані щодо того, варто мені чи ні використовувати їх.

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

Попередні проекти Java / Swing Я певною мірою використовував вкладені класи, однак тепер я перейшов до інших проектів на C # і уникаю їх використання.

Як ви ставитесь до вкладених занять?

Ну, і простіше кажучи: вкладені класи не порушують інкапсуляцію і в цілому мовні функції не порушують принципів програмування. Програмісти порушують принципи програмування.

Як не дивно, заявлені вкладені класи збільшують інкапсуляцію :

Посилена інкапсуляція - розглянемо два класи вищого рівня, A і B, де B потрібен доступ до членів A, які в іншому випадку будуть оголошені приватними. Приховуючи клас B у класі A, члени A можуть бути оголошені приватними, і B може отримати доступ до них. Крім того, сам Б може бути прихований від зовнішнього світу.

У цьому є деяка правда.

Зазвичай B є результатом застосування SRP до A. B, однак потенційно порушує багато принципів, особливо, якщо все, що він робить, це спіткання з приватними членами A: D

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

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

Суть полягає в тому, що це полегшує читання / запис коду, і рідко трапляється такий випадок, коли вам знадобиться клас замовлення та не потрібно знати про OrderItems.

Особисто я відчуваю, що їх слід уникати, оскільки вони поєднують ваш дизайн різними (як правило, несприятливими) способами.

Однак якщо ваш проект має задану область застосування та інкапсуляцію класу (наприклад, клас Node або якийсь об’єкт, який використовується для переходу структури даних певного класу), я не бачу шкоди.

Насправді, я думаю, що для певних типів проектів це робить код (і міркування) більш розбірливим / легким для розуміння. Однак я вважаю, що для більшості проектів з розширенням на увазі це погана ідея, оскільки рідко відокремлення їх може спричинити вам проблеми, але, якщо ви будете разом, це може змусити вас розв’язати їх у майбутньому (що витрачається на витрачений час).

(В C #) Взагалі я б їх уникав, хоча це може точно залежати від того, яка мета класу.

Я б ніколи не використовував їх для будь-якого класу доменних моделей, що просто не має для мене сенсу.

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

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