Classes imbriquées: un outil utile ou une violation d'encapsulation?

Je ne sais donc toujours pas si je dois les utiliser ou non.

Je pense que c'est une violation extrême de l'encapsulation, mais je trouve que je suis capable d'atteindre un certain degré d'encapsulation tout en gagnant plus de flexibilité dans mon code.

Projets Java / Swing précédents J'avais utilisé des classes imbriquées dans une certaine mesure, mais maintenant je suis passé à d'autres projets en C # et j'évite leur utilisation.

Que pensez-vous des classes imbriquées?

Eh bien, trop simplement: les classes imbriquées ne violent pas l'encapsulation et en général, les fonctionnalités du langage ne violent pas les principes de programmation. Les programmeurs violent les principes de programmation.

Curieusement, les classes imbriquées augmentent l'encapsulation :

Encapsulation accrue - Considérez deux classes de niveau supérieur, A et B, où B a besoin d'accéder aux membres de A qui seraient autrement déclarés privés. En cachant la classe B dans la classe A, les membres de A peuvent être déclarés privés et B peut y accéder. De plus, B lui-même peut être caché du monde extérieur.

Il y a du vrai là-dedans.

Habituellement, B est le résultat de l'application de la SRP à A. B lui-même, cependant, peut potentiellement violer de nombreux principes, en particulier, s'il ne fait que jouer avec les membres privés de A: D

Je pense que les classes cachées peuvent être utiles. Mais il y a beaucoup de risques d'abus.

Nous utilisons tout le temps des classes imbriquées. Dans de nombreuses situations, les logiciels / processus métier ont des objets métier imbriqués. Nous avons tous vu l'exemple d'un objet Order qui a une collection imbriquée de OrderItems.

L'essentiel est que cela facilite la lecture / écriture du code et il y a rarement un cas où vous auriez besoin de votre classe Order et pas besoin de connaître OrderItems.

Personnellement, je pense qu'ils devraient être évités car ils associent votre conception de diverses manières (généralement défavorables).

Cependant, si votre projet a une portée définie et encapsule une classe (telle qu'une classe Node ou une sorte d'objet utilisé pour parcourir la structure de données d'une classe spécifique), je ne vois pas le mal.

En fait, je pense que pour certains types de projets, cela rend le code (et le raisonnement) plus lisible / facile à comprendre. Cependant, je pense que pour la plupart des projets avec extensibilité à l'esprit, c'est une mauvaise idée, car rarement les séparer vous causera des problèmes, mais les laisser ensemble peut vous obliger à les découpler à l'avenir (ce qui est une perte de temps).

(En C #) En général, je les éviterais, bien que cela puisse dépendre exactement de l'objectif de la classe.

Je ne les utiliserais jamais pour aucun type de classe de modèle de domaine, cela n'a tout simplement aucun sens pour moi.

J'avais l'habitude de les utiliser pour structurer des données privées dans la classe externe, mais j'ai constaté que celles-ci finissent presque toujours par être utilisées en externe plus tard dans le cycle de vie du projet, donc je ne m'embête plus généralement avec cela.

La seule fois où je les utilise maintenant, c'est pour l'étrange petite astuce de codage où l'utilisation d'une autre petite classe facilite l'implémentation d'une classe particulière, ou l'implémentation d'une interface qui n'est vraiment qu'un modèle de notification d'événement (où la classe interne implémentera une interface et passera simplement contrôler la classe externe).