La puissance des langages à objets au service de l'utilisateur
Les recherches en génie logiciel permettent aujourd'hui d'exploiter des langages de programmation dédiés au type de problème évoqué : mettre en relation un grand nombre de classe[1] d'objets, porteuses de significations et de comportements différents. Ce sont les langages, et les bases de données dites «orienté objet[2]», largement utilisés dans les NTIC[3].
Sans entrer dans les détails, on peut dire que toute une série de nouveaux concepts de programmation permettent
de condenser le code, de le rendre modulaire,
de le rendre général, c'est à dire de diminuer la partie que l'éditeur doit développer, en mettant à sa disposition des bibliothèques de fonctions,
de structurer les données pour les hiérarchiser, pour les rendre facilement évolutives,
de simplifier l'écriture des procédures, car c'est le langage qui se charge de gérer la combinatoire des possibilités, de se rendre compte si une action demandée par l'utilisateur est autorisée ou non.
On serait tenté d'affirmer que ce sont des avantages au bénéfice des informaticiens qui ne concernent pas l'utilisateur. Erreur !
Ces performances de langage de programmation permettent de réduire les investissements tout en autorisant une puissance de traitement impossible à atteindre en programmation traditionnelle (algorithmique): le code serait volumineux, la durée de développement trop longue, avec pour conséquence des coûts de production élevés, et une fiabilité du logiciel aléatoire (réparer un « bug » en provoque souvent d'autres !).
Le concept de description le plus fondamental des langages à objets est celui de « classe[1] », c'est à dire la possibilité de décrire des propriétés[4] et un comportement qui s'appliqueront ultérieurement à un ensemble d'entités réelles appelées « occurrence[5] ».
L'avantage est de décrire des modèles abstraits, et de décliner un certain nombre d'exceptions avec le concept de « sous classes », en utilisant des fonctions de programmation toutes faites d'une application à l'autre, car générales. D'où une économie d'investissement, alors que la structure de données décrite peut être complexe !
Un concept fondamental, de procédure cette fois, est celui d'« événement[6] » qui déclenche une « action[7] » lorsque certaines conditions se réalisent dans l'environnement d'une entité.
A chaque classe d'entités on peut associer ainsi, par avance, un ensemble d'actions possibles, chaque action pouvant à son tour modifier le contexte de l'environnement d'un autre objet, et ainsi de suite, pour provoquer des actions en cascade. Ce qui est important, c'est que ces actions s'exécutent automatiquement, sans la volonté explicite de celui qui les a provoquées.
Par exemple, l'opérateur ayant volontairement déplacé un mur dans le projet, le logiciel se charge alors tout seul d'allonger ou rétrécir les murs adjacents, et même dans certains cas, de modifier également les planchers, de déplacer certaines ouvertures ...
