En cherchant à expliquer pourquoi, dans les langages orientés objet, des classes avec de trop nombreuses variables membres étaient 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 direct à une variable globale.

Autre soucis, si l'unité de compilation devient grande, et si son nombre de variables 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 se retrouver avec un état qui change on ne sait pas trop pourquoi, et on ne sait trop quand. Et ça finit 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 membres. À ce niveau, on se retrouve avec... des variables accessibles par potentiellement toutes les fonctions membres, qui peuvent l'être à n'importe quel moment, pour n'importe quelle 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 de les maintenir.

Si la classe se met à avoir de plus en plus de variables membres, ces invariants deviennent complexes à 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'une classe, la règle reste la même : rester petit, rester compréhensible, afin de garder le contrôle.