Verschachtelte Klassen: Ein nützliches Tool oder eine Kapselungsverletzung?

Ich bin also immer noch am Zaun, ob ich diese verwenden soll oder nicht.

Ich halte es für eine extreme Verletzung der Kapselung, finde jedoch, dass ich einen gewissen Grad an Kapselung erreichen und gleichzeitig mehr Flexibilität in meinem Code erlangen kann.

Frühere Java / Swing-Projekte Ich hatte bis zu einem gewissen Grad verschachtelte Klassen verwendet. Jetzt bin ich jedoch in andere Projekte in C # umgezogen und vermeide deren Verwendung.

Wie denkst du über verschachtelte Klassen?

Einfach ausgedrückt: Verschachtelte Klassen verletzen nicht die Kapselung, und im Allgemeinen verstoßen Sprachfunktionen nicht gegen Programmierprinzipien. Programmierer verstoßen gegen Programmierprinzipien.

Komischerweise wird behauptet, dass verschachtelte Klassen die Kapselung erhöhen :

Erhöhte Kapselung - Betrachten Sie zwei Klassen der obersten Ebene, A und B, wobei B Zugriff auf Mitglieder von A benötigt, die andernfalls als privat deklariert würden. Durch das Ausblenden von Klasse B in Klasse A können die Mitglieder von A als privat deklariert werden und B kann auf sie zugreifen. Außerdem kann B selbst vor der Außenwelt verborgen sein.

Darin liegt etwas Wahres.

Normalerweise ist B das Ergebnis der Anwendung von SRP auf A. B selbst verstößt jedoch möglicherweise gegen viele Prinzipien, insbesondere wenn es nur mit den privaten Mitgliedern von A herumspielt: D.

Ich denke, versteckte Klassen können nützlich sein. Es gibt jedoch viel Potenzial für Missbrauch.

Wir verwenden ständig verschachtelte Klassen. In vielen Situationen haben Unternehmenssoftware / -prozesse verschachtelte Geschäftsobjekte. Wir haben alle das Beispiel eines Order-Objekts gesehen, das eine verschachtelte Sammlung von OrderItems enthält.

Das Fazit ist, dass es das Lesen / Schreiben des Codes erleichtert und es selten einen Fall gibt, in dem Sie Ihre Order-Klasse benötigen und nicht über OrderItems Bescheid wissen müssen.

Persönlich denke ich, dass sie vermieden werden sollten, da sie Ihr Design auf verschiedene (normalerweise ungünstige) Arten koppeln.

Wenn Ihr Projekt jedoch einen festgelegten Bereich hat und eine Klasse kapselt (z. B. eine Knotenklasse oder eine Art Objekt, das zum Durchlaufen der Datenstruktur einer bestimmten Klasse verwendet wird), sehe ich keinen Schaden.

Tatsächlich denke ich, dass es für bestimmte Arten von Projekten den Code (und die Argumentation) lesbarer / verständlicher macht. Ich denke jedoch, dass es für die meisten Projekte mit Blick auf die Erweiterbarkeit eine schlechte Idee ist, da eine Trennung selten zu Problemen führt. Wenn Sie sie jedoch zusammen lassen, können Sie sie möglicherweise in Zukunft entkoppeln (was Zeitverschwendung ist).

(In C #) Im Allgemeinen würde ich sie vermeiden, obwohl es genau davon abhängen kann, welchen Zweck die Klasse hat.

Ich würde sie niemals für irgendeine Art von Domain-Modellklasse verwenden, das macht für mich einfach keinen Sinn.

Früher habe ich sie zum Strukturieren von Daten verwendet, die in der äußeren Klasse privat sind, aber ich habe festgestellt, dass diese fast immer später im Lebenszyklus des Projekts extern benötigt werden, sodass ich mich im Allgemeinen nicht mehr darum kümmere.

Das einzige Mal, dass ich sie jetzt verwende, ist für den seltsamen kleinen Codierungstrick, bei dem die Verwendung einer anderen kleinen Klasse die Implementierung einer bestimmten Klasse erleichtert oder eine Schnittstelle implementiert, die eigentlich nur ein Ereignisbenachrichtigungsmuster ist (bei dem die interne Klasse eine Schnittstelle implementiert und nur übergibt Kontrolle über die äußere Klasse).