I. Qu'est-ce qu'un objet ?▲
Effectivement, un objet c'est bien des données et des traitements que l'on a regroupé au sein d'un même concept : la classe.
D'ailleurs, ne confondons pas classe et objet, la classe c'est le concept, la définition et les objets sont les instances de la classe, les « vrais » objets, ceux que l'on peut « toucher ».
Mais quels sont ces traitements dont on parle ? Sont-ce les mêmes que lorsque l'on parle de données-traitements, je veux dire quand on parle des données et des procédures et fonctions qui traitent ces données au sens des langages dits procéduraux comme C ou COBOL ?
Un Normand vous répondrait : ça dépend, oui et non. Et il aurait raison, car sans en dire plus sur la réelle nature d'un objet, on ne peut aller plus loin dans l'explication.
II. Choisir les bons traitements▲
Prenons donc un exemple simple, la classique classe Commande, que l'on peut considérer au moins dans un premier temps comme une simple donnée.
Je passe la définition des différents attributs possibles de cette classe ainsi que les relations qu'elle peut avoir avec d'autres classes comme le client, le magasin ou encore les articles.
Quels sont les traitements que vous feriez supporter à cette classe ? Imprimer ? Facturer ? Calculer solde ? Calculer poids ?
Il n'y a certainement pas une solution unique, mais si vous faites supporter toutes ces opérations à la classe Commande, je vous poserai seulement une question :
« Avez-vous bien mesuré les conséquences de toutes ces responsabilités que vous faites supporter à cette pauvre petite classe ? »
Car faire supporter une opération à une classe (et donc à un objet), c'est lui attribuer des responsabilités supplémentaires. Et toutes les qualités d'un bon modèle objet se résument finalement en une bonne répartition réfléchie des responsabilités au sein des différentes classes.
Si tous les traitements qui manipulent la Commande (sorte de donnée) sont supportés par la Commande, votre classe risque de se transformer rapidement en un gros Bibendum. Vous aurez du mal à répartir le travail sur cette classe au sein de l'équipe projet, vous serez obligé de modifier la classe pour modifier un traitement déjà réalisé par elle et vous aurez du mal à utiliser la classe dans un autre contexte sans tirer tout le contexte existant (les traitements existants).
Donc, nos fameux traitements, ceux que l'on veut faire supporter à notre Commande doivent être ceux que l'on juge intrinsèques au concept de Commande. Ceux que l'on juge valables dans différents contextes d'utilisation. Et ce même si vous n'avez pas encore l'intention de faire de la réutilisation. Et c'est là que finalement revient notre bonne vieille distinction données-traitements.
III. Objet donnée - Objet traitement▲
Dans le monde objet, comme dans le monde du procédural, il y a bien des données et des traitements. Et une bonne conception objet fait donc la distinction entre ces deux concepts.
III-A. Les données▲
Les données du monde objet sont ce que l'on appelle les Entités (entity en anglais). Les classes « entités » qu'une méthode comme les RUP(1) propose de modéliser en UML avec le stéréotype « entity » (
) représentent donc les données manipulées par une application, les données que classiquement on stocke dans une base de données. Bien sûr, ces classes comportent des opérations, des traitements donc, mais ces opérations doivent être comme on l'a dit, intrinsèques à l'entité, jugés comme valables indépendamment du contexte actuel de l'application qui crée cette entité.
III-B. Les traitements▲
Les traitements qui ne seront pas intrinsèques aux entités, c'est-à-dire souvent des traitements qui manipulent plusieurs entités, différentes ou non, ou qui sont très spécifiques, sont ce que l'on appelle les Contrôleurs (stéréotype Control
dans le RUP). Ces contrôleurs réaliseront donc un certain nombre de traitements eux-mêmes ou pourront enchaîner des traitements réalisés par d'autres contrôleurs ou entités.
Une telle séparation entre entités et contrôleurs, et d'une certaine manière entre données et traitements, n'est aucunement contradictoire avec les concepts de l'objet, car nous verrons par la suite que certaines caractéristiques propres au monde objet nous aideront à concevoir des entités et des contrôleurs plus « évolués » que les classiques données et traitements du monde procédural. Cette séparation entre les données et les traitements apporte de plus un certain nombre d'avantages comme :
- permettre de réutiliser les données sans les traitements ;
- faciliter la répartition du travail au sein d'une équipe ;
- faciliter la répartition des données et des traitements sur les différents tiers d'une architecture n-tiers :
- faciliter le packaging des données et des traitements au sein de modules différents :
- faciliter le choix dynamique de certains traitements par l'application.(2)
Bon, eh bien qu'est-ce qui fait la différence entre le monde objet et le monde procédural alors ?
IV. Les apports de l'objet▲
On peut déjà noter qu'une différence entre nos entités et les classiques données du monde procédural est que les entités sont des classes et donc elles supportent un certain nombre d'opérations (nos traitements intrinsèques).
Sinon, que ce soit les contrôleurs ou les entités, ces classes supportent tous les mécanismes propres à l'objet comme la généralisation/spécialisation, le polymorphisme ou encore l'encapsulation.
Un mécanisme comme la généralisation/spécialisation va permettre de définir ce que l'on appelle des interfaces. Ces interfaces vont permettre de définir des traitements plus ou moins génériques sachant manipuler différentes entités ou contrôleurs implémentant ces interfaces. L'encapsulation va, elle, permettre de créer des sortes de composants offrant des services via des interfaces tout en cachant l'implémentation de ces services.
Nos contrôleurs, que l'on a assimilé à des traitements ont de plus l'avantage de pouvoir agréger plusieurs traitements (ils offrent alors plusieurs services) normalement « éparpillés » dans le monde procédural.
Ok, donc avec l'objet on a toujours les données et les traitements plus ou moins séparés, mais les données sont des « super données intelligentes » et les traitements sont en fait des « paquets de traitements »
Très bien et alors ?
V. Modélisation objet et langage de programmation▲
V-A. Le monde objet n'est pas un monde à part !▲
Désacralisons un peu le monde objet. Le monde objet qui n'est pas un monde dans une dimension parallèle, on l'a vu, nos bonnes vieilles données et nos bons vieux traitements existent toujours et sont globalement toujours séparés. Il n'existe donc pas vraiment une espèce bizarre et indéfinie qu'on appellerait « objet » et qui n'aurait rien à voir avec nos données-traitements.
Aussi, les habitudes prises par les personnes venant du monde procédural (vous peut-être !) comme C ou COBOL ne doivent pas être reniées totalement. Ces habitudes doivent juste être adaptées aux nouvelles possibilités offertes par l'objet.
V-B. UML pour le monde procédural▲
Le mode de pensée de l'objet n'étant pas si éloigné du monde procédural, il est toujours possible, voire intéressant et utile, de modéliser une application en objet, avec UML par exemple, même si le langage de programmation n'est pas un langage dit objet.
Une modélisation objet permettra d'offrir une représentation plus proche de l'utilisateur, plus proche du réel et donc plus compréhensible et plus adaptée aux utilisateurs et aux compétences des nouveaux programmeurs.
Le passage de la modélisation objet au langage C ou COBOL, par exemple, ne sera pas si complexe que cela. Les entités seront transformées en structures C ou clauses COPY COBOL pour leur partie pure « données » (les attributs) et les contrôleurs et opérations des entités en programmes C ou programmes COBOL. Les autres concepts comme le polymorphisme ou la généralisation/spécialisation peuvent aussi être implémentés avec des langages comme C ou COBOL(3). Je n'entrerai pas ici dans les détails des différentes solutions, mais si on fait en plus un usage limité de ces concepts en modélisation(4), le passage au code sera assez simple.
V-C. Retour sur une séparation…▲
Si on a vu que la séparation données - traitements pouvait exister aussi dans le monde objet, c'est à la fois parce qu'un parallèle peut être fait, mais peut-être aussi parce qu'il est fondamental de faire cette séparation.
Je veux dire que si j'ai parlé d'entités et de contrôleurs, ce n'est pas pour essayer de faire un parallèle entre les données et les traitements du monde procédural, mais parce que je pense QU'IL FAUT ABSOLUMENT FAIRE CETTE SÉPARATION POUR FAIRE DE LA BONNE CONCEPTION OBJET.
C'est peut-être en partie pour cela que les nouvelles architectures s'orientent vers un découplage données - traitements. On parle beaucoup des architectures orientées services (SOA) comme les WebServices (WebTraitements ! qui reprennent en fait CORBA à la sauce Web/XML). C'est peut-être un effet de mode, mais je pense que c'est surtout la marque d'une évolution plus profonde (maturité ?) de la vision que l'on peut avoir du monde objet. Alors OK, le découplage données - traitements dans le monde des architectures distribuées répond aussi à un besoin inhérent à ces architectures : la donnée doit passer du serveur au client, mais cette évolution montre aussi le chemin que devront prendre nos modes de conception objet, car, distribuée ou pas, notre application sera mieux conçue en séparant ses données et ses traitements.
VI. Conclusion▲
J'espère que vous aurez compris que les pratiques de l'Objet ne sont pas si éloignées des pratiques du monde procédural et qu'il n'y a pas de honte à créer des données et des traitements séparés, même en Objet. Je dirai même que cela apporte pas mal d'avantages ensuite par rapport à des contraintes d'architecture ou des besoins de modularité et réutilisation.
Bon les programmeurs C et COBOL, quand est-ce que l'on vous voit sur le forum UML :-) !