Klasy zagnieżdżone: przydatne narzędzie czy naruszenie enkapsulacji?

Więc wciąż jestem na ogrodzeniu, czy mam ich używać, czy nie.

Wydaje mi się, że jest to skrajne naruszenie enkapsulacji, jednak okazuje się, że jestem w stanie osiągnąć pewien stopień enkapsulacji, jednocześnie zyskując większą elastyczność w kodzie.

Poprzednie projekty Java / Swing korzystałem do pewnego stopnia z klas zagnieżdżonych, jednak teraz przeniosłem się do innych projektów w języku C # i unikam ich użycia.

Co sądzisz o klasach zagnieżdżonych?

Cóż, mówiąc wprost: klasy zagnieżdżone nie naruszają enkapsulacji i, ogólnie rzecz biorąc, funkcje językowe nie naruszają zasad programowania. Programiści łamią zasady programowania.

Co zabawne, twierdzi się, że zagnieżdżone klasy zwiększają enkapsulację :

Zwiększona enkapsulacja - Rozważ dwie klasy najwyższego poziomu, A i B, w których B potrzebuje dostępu do członków A, które w innym przypadku zostałyby uznane za prywatne. Ukrywając klasę B w klasie A, członkowie A mogą zostać uznani za prywatnych, a B może uzyskać do nich dostęp. Ponadto sam B można ukryć przed światem zewnętrznym.

Jest w tym trochę prawdy.

Zwykle B jest wynikiem zastosowania SRP do samego A. B jednak potencjalnie narusza wiele zasad, szczególnie jeśli wszystko, co robi, to kręcenie się z prywatnymi członkami A: D

Myślę, że ukryte klasy mogą być przydatne. Ale istnieje duży potencjał niewłaściwego użytkowania.

Cały czas korzystamy z klas zagnieżdżonych. W wielu sytuacjach oprogramowanie / procesy biznesowe zagnieżdżają obiekty biznesowe. Wszyscy widzieliśmy przykład obiektu Order, który ma zagnieżdżoną kolekcję OrderItems.

Najważniejsze jest to, że ułatwia to czytanie / pisanie kodu i rzadko zdarza się, że potrzebujesz klasy Order i nie musisz wiedzieć o OrderItems.

Osobiście uważam, że należy ich unikać, ponieważ łączą Twój projekt na różne (zwykle niekorzystne) sposoby.

Jeśli jednak twój projekt ma ustawiony zakres i zawiera klasę (na przykład klasę Node lub jakiś obiekt używany do przechodzenia przez strukturę danych konkretnej klasy), nie widzę szkody.

W rzeczywistości myślę, że w przypadku niektórych typów projektów kod (i rozumowanie) jest bardziej czytelny / łatwy do zrozumienia. Myślę jednak, że w przypadku większości projektów z myślą o rozszerzalności jest to zły pomysł, ponieważ rzadko ich rozdzielanie powoduje problemy, ale pozostawienie ich razem może zmusić cię do ich oddzielenia w przyszłości (co jest stratą czasu).

(W C #) Ogólnie bym ich unikał, chociaż może to zależeć dokładnie od tego, jaki jest cel klasy.

Nigdy nie użyłbym ich do jakiejkolwiek klasy modelu domeny, co nie ma dla mnie sensu.

Kiedyś używałem ich do konstruowania danych, które są prywatne w klasie zewnętrznej, ale odkryłem, że prawie zawsze są one potrzebne na zewnątrz w późniejszym etapie cyklu życia projektu, więc generalnie nie zawracam sobie tym głowy.

Teraz używam ich tylko do dziwnej sztuczki kodowania, w której użycie innej małej klasy ułatwia implementację konkretnej klasy lub implementację interfejsu, który jest tak naprawdę tylko wzorcem powiadamiania o zdarzeniu (gdzie klasa wewnętrzna zaimplementuje interfejs i po prostu przejdzie kontrolować z powrotem klasę zewnętrzną).