En cherchant à expliquer pourquoi, dans les langages orientés objet, des classes avec de trop nombreuses variables membre était une mauvaise idée, je suis arrivé à cette considération : au zoom, avoir de nombreuses variables membres, c'est comme avoir de nombreuses variables globales. Juste à un niveau plus local.

La considération peut sembler alambiquée.

Partons d'un langage procédural simple et sans notion de classe. Le C. Il est possible en C de faire de l'encapsulation : en n'exposant depuis les unités de compilation uniquement l'interface publique, et en spécifiant tout ce qui doit être caché sous forme de statiques. Cependant, dès que l'on permet d'accéder librement aux variables d'une unité de compilation depuis un autre endroit en écriture, le problème des globales survient.

C'est ce que l'on peut regrouper sous le terme : « les variables globales, c'est Mal ».

On trouvera toujours des bonnes raisons pour donner accès à des variables globales. Vous savez bien... « celle-ci » parce que... oh parce que c'est plus simple.

Et mettre l'accès à ces variables derrière une fonction qui peut en modifier la valeur directement ne change rien. Cela reste un accès directe à une variable globale.

Autre soucis, si l'unité de compilation devient grande, et si son nombre de variable augmente, il devient complexe de tracer l'évolution des états des variables.

On se retrouve alors rapidement avec des variables pouvant être modifiées depuis n'importe où ; il est très rapide de perdre le fil, et de ce retrouver avec un état qui change on ne sait pas trop pourquoi, et on ne sait trop quand. Et ça fini par des accès concurrentiels à protéger à coup de mutex et une dégradation lente et inéluctable du système. Et beaucoup de prise de tête.

Passons maintenant dans un langage orienté objet. C++, Java, C#,... choisissez, en ce qui concerne ce point, ils sont identiques.

Zoomons à présent sur une classe contenant des variables membres. Mettons-nous au niveau de cette classe. Tout le décors de la classe disparaît, il n'existe plus que les variables et les fonctions membre. À ce niveau, on se retrouve avec... des variables accessibles par potentiellement toutes les fonctions membre, qui peuvent l'être à n'importe quel moment, pour n'importe quel raison. Si ces variables sont publiques, elles sont accessibles par le monde extérieur sans restriction, à n'importe quel moment et pour n'importe quelle raison.

Autrement dit, on se retrouve avec l'exact même problème au niveau d'une classe qu'au niveau d'un programme en entier.

Une chose importante : la raison même de l'existence d'un objet, c'est d'avoir des invariants sur lesquels on puisse raisonner. Certes, il y aussi la notion de polymorphisme, mais laissons ça de côté. Les objets ont des invariants, et l'encapsulation permet des les maintenir.

Si la classe se met à avoir de plus en plus de variables membres, ces invariants deviennent complexe à maintenir. Si les variables membres peuvent être modifiées par le monde extérieur, garder des invariants est impossible sans la coopération d'autres parties du programme, ce qui défait toute idée d'encapsulation.

Ainsi, que ce soit au niveau d'un programme en entier ou au niveau d'un classe, la règle reste la même : rester petit, rester compréhensible, afin de garder le contrôle.