Developpez.

com
Club des Dveloppeurs

Objets, donnes, traitements et modlisation

Auteur : Erik Gollot (ego) Ah lobjet ! Cest super ! La runification des donnes et des traitements, le tout en un. Fini les donnes dun ct et les traitements de lautre, has been tout a, vive lavnement de lobjet et de la modlisation objet. Moi, Monsieur, je pense Objet, je modlise Objet, je programme Objet, je dors Objet, je mange Objet, je mhabille Objet, je bois Objet, je Euh, jy vais un peu fort l ! On constate souvent ce genre de discours, sauf les quelques derniers mots peut tre, et cette opposition qui est faite entre lobjet et le lgendaire couple donnes-traitements. On fait dailleurs souvent ce raccourci pour dfinir ce quest un objet : cest comme une donne avec les traitements en plus Sommes nous vraiment srs que cette explication ou cette opposition soient justes ? Matrisons-nous rellement la porte de ce raccourci : cest comme une donne avec les traitements en plus ? La fusion complte des donnes et des traitements est-elle relle en objet ? Essayons donc de voir quelle est la vraie nature de lObjet et en quoi lapproche objet a apport de la nouveaut dans nos pratiques dinformaticiens (et ciennes bien entendu !)

Quest ce quun objet ?

Effectivement, un objet cest bien des donnes et des traitements que lon a regroup au sein dun mme concept : la classe.
Client
nom prenom date de naissance donneAge()
Traitement qui donne lage du client

Dailleurs ne confondons pas classe et objet, la classe cest le concept, la dfinition et les objets sont les instances de la classe, les vrais objets, ceux que lon peut toucher .
La classe Client
nom prenom date de naissance

Les objets

Mr X : Client
nom = X prenom = paul date de naissance = 27/07/68

Mme Y : Client
nom = Y prenom = lucy date de naissance = 03/02/54

Mais quels sont ces traitements dont on parle ? Sont-ce les mmes que lorsque lon parle de donnes-traitements, je veux dire quand on parle des donnes et des procdures et fonctions qui traitent ces donnes au sens des langages dits procduraux comme C ou COBOL ?

Un Normand vous rpondrait : a dpend, oui et non. Et il aurait raison car sans en dire plus sur la relle nature dun objet, on ne peut aller plus loin dans lexplication.

Choisir les bons traitements

Prenons donc un exemple simple, la classique classe Commande, que lon peut considrer au moins dans un premier temps comme une simple donne. Je passe la dfinition des diffrents attributs possibles de cette classe ainsi que les relations quelle peut avoir avec dautres 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 ?

Commande
Imprimer() Facturer() CalculerSolde() CalculerPoids()

Il ny a certainement pas une solution unique mais si vous faites supporter toutes ces oprations la classe Commande, je vous poserai seulement une question : Avez-vous bien mesur les consquences de toutes ces responsabilits que vous faites supporter cette pauvre petite classe ? Car faire supporter une opration une classe (et donc un objet), cest lui attribuer des responsabilits supplmentaires. Et toutes les qualits dun bon modle objet se rsument finalement en une bonne rpartition rflchie des responsabilits au sein des diffrentes classes. Si tous les traitements qui manipulent la Commande (sorte de donne) sont supports par la Commande, votre classe risque de se transformer rapidement en un gros bibendum. Vous aurez du mal rpartir le travail sur cette classe au sein de lquipe projet, vous serez oblig de modifier la classe pour modifier un traitement dj ralis 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 lon veut faire supporter notre Commande doivent tre ceux que lon juge intrinsques au concept de Commande. Ceux que lon juge valables dans diffrents contextes dutilisation. Et ce mme si vous navez pas encore lintention de faire de la rutilisation. Et cest l que finalement revient notre bonne vieille distinction donnes-traitements.

Objet donne Objet traitement

Dans le monde objet, comme dans le monde du procdural, il y a bien des donnes et des traitements. Et une bonne conception objet fait donc la distinction entre ces 2 concepts.

Les donnes
Les donnes du monde objet sont ce que lon appelle les Entits (entity en anglais). Les classes entits quune mthode comme les RUP1 propose de modliser en UML avec le strotype entity ( ) reprsentent donc les donnes manipules par une application, les donnes que classiquement on stocke dans une base de donnes. Bien sr, ces classes comportent des oprations, des traitements donc, mais ces oprations doivent tre comme on la dit, intrinsques lentit, jugs comme valables indpendamment du contexte actuel de lapplication qui cr cette entit.

Rational Unified Process

Les traitements
Les traitements qui ne seront pas intrinsques aux entits, c'est--dire souvent des traitements qui manipulent plusieurs entits, diffrentes ou non, ou qui sont trs spcifiques, sont ce que lon appelle les Contrleurs (strotype Control dans le RUP). Ces contrleurs raliseront donc un certain nombre de traitements eux-mmes ou pourront enchaner des traitements raliss par dautres contrleurs ou entits.

Commande

CommandeManager

CommandeEditor

numero lieu expedition date prise commande type livraison

CalculerPoids() CalculerSolde() Facturer()

Imprimer()

Une telle sparation entre entits et contrleurs, et dune certaine manire entre donnes et traitements, nest aucunement contradictoire avec les concepts de lobjet car nous verrons par la suite que certaines caractristiques propres au monde objet nous aiderons concevoir des entits et des contrleurs plus volus que les classiques donnes et traitements du monde procdural. Cette sparation entre les donnes et les traitements apporte de plus un certain nombre davantages comme : Permettre de rutiliser les donnes sans les traitements Facilite la rpartition du travail au sein dune quipe Facilite la rpartition des donnes et des traitements sur les diffrents tiers dune architecture n-tiers Facilite le packaging des donnes et des traitements au sein de modules diffrents Facilite le choix dynamique de certains traitements par lapplication2 Bon, eh bien quest ce qui fait la diffrence entre le monde objet et le monde procdural alors ?

Les apports de lobjet

On peut dj noter quune diffrence entre nos entits et les classiques donnes du monde procdural est que les entits sont des classes et donc elles supportent un certain nombre doprations (nos traitements intrinsques). Sinon, que ce soit les contrleurs ou les entits, ces classes supportent tous les mcanismes propres lobjet comme la gnralisation/spcialisation, le polymorphisme ou encore lencapsulation.
ClientEditor Client
Gnralisation/spcialisation

Imprimer(Client c)

Particulier

Entreprise

ClientEditorPDF

ClientEditorExcel

- siret + getSiret()
Encapsulation Le numro siret nest accessible que via lopration getSiret

Imprimer(Client c)

Imprimer(Client c)

Polymorphisme

Un design pattern comme la Stratgie utilise ce principe

Un mcanisme comme la gnralisation/spcialisation va permettre de dfinir ce que lon appelle des interfaces. Ces interfaces vont permettre de dfinir des traitements plus ou moins gnriques sachant manipuler diffrentes entits ou contrleurs implmentant ces interfaces. Lencapsulation va, elle, permettre de crer des sortes de composants offrant des services via des interfaces tout en cachant limplmentation de ces services. Nos contrleurs, que lon a assimil des traitements ont de plus lavantage de pouvoir agrger plusieurs traitements (ils offrent alors plusieurs services) normalement parpills dans le monde procdural. Ok, donc avec lobjet on a toujours les donnes et les traitements plus ou moins spars mais les donnes sont des supers donnes intelligentes et les traitements sont en fait des paquets de traitements Trs bien et alors ?

Modlisation objet et langage de programmation

Si jai voulu insister sur cet aspect donnes-traitements qui perdure mme dans le monde objet, cest pour plusieurs raisons.

Le monde objet nest pas un monde part !

Dsacralisons un peu le monde objet. Le monde objet qui nest pas un monde dans une dimension parallle, on la vu, nos bonnes vieilles donnes et nos bons vieux traitements existent toujours et sont globalement toujours spars. Il nexiste donc pas vraiment une espce bizarre et indfinie quon appellerait objet et qui naurait rien voir avec nos donnes-traitements. Aussi, les habitudes prises par les personnes venant du monde procdural (vous peuttre !) comme C ou COBOL ne doivent pas tre renies totalement. Ces habitudes doivent justes tre adaptes aux nouvelles possibilits offertes par lobjet.

UML pour le monde procdural

Le mode de pense de lobjet ntant pas si loign du monde procdural, il est toujours possible, voir intressant et utile, de modliser une application en objet, avec UML par exemple, mme si le langage de programmation nest pas un langage dit objet. Une modlisation objet permettra doffrir une reprsentation plus proche de lutilisateur, plus proche du rel et donc plus comprhensible et plus adapte aux utilisateurs et aux comptences des nouveaux programmeurs. Le passage de la modlisation objet au langage C ou COBOL, par exemple, ne sera pas si complexe que cela. Les entits seront transformes en structures C ou clauses COPY COBOL pour leur partie pure donnes (les attributs) et les contrleurs et oprations des entits en programmes C ou programmes COBOL. Les autres concepts comme le polymorphisme ou la gnralisation/spcialisation peuvent aussi tre implments avec des langages comme C ou COBOL3. Je nentrerai pas ici dans les dtails des diffrentes solutions mais si on fait en plus un usage limit de ces concepts en modlisation4, le passage au code sera assez simple.

Retour sur une sparation

Si on a vu que la sparation donnes traitements pouvait exister aussi dans le monde objet, cest la fois parce quun parallle peut tre fait, mais peut tre aussi parce quil est fondamental de faire cette sparation. Je veux dire que si jai parl dentits et de contrleurs, ce nest pas pour essayer de faire un parallle entre les donnes et les traitements du monde procdural mais parce que je pense QUIL FAUT ABSOLUMENT FAIRE CETTE SEPARATION POUR FAIRE DE LA BONNE CONCEPTION OBJET. Cest peut tre en partie pour cela que les nouvelles architectures sorientent vers un dcouplage donnes traitements. On parle beaucoup des architectures orientes services (SOA) comme les WebServices (WebTraitements ! qui reprennent en fait CORBA
3 Rappelons nous que les premiers compilateurs C++ faisant dabord une gnration en langage C pour ensuite utiliser la compilation C 4 Mme avec un langage objet il est recommand de ne pas abuser de la notion de gnralisation/spcialisation. Un ou 2 niveaux dans un arbre dhritage est gnralement suffisant.

 la sauce Web/XML). Cest peut tre un effet de mode mais je pense que cest surtout la marque dune volution plus profonde (maturit ?) de la vision que lon peut avoir du monde objet. Alors ok, le dcouplage donnes traitements dans le monde des architectures distribues rpond aussi un besoin inhrent ces architectures : la donne doit passer du serveur au client, mais cette volution montre aussi le chemin que devront prendre nos modes de conception objet car, distribue ou pas, notre application sera mieux conue en sparant ses donnes et ses traitements.

Conclusion
Jespre que vous aurez compris que les pratiques de lObjet ne sont pas si loignes des pratiques du monde procdural et quil ny a pas de honte crer des donnes et des traitements spars, mme en Objet. Je dirai mme que cela apporte pas mal davantages ensuite par rapport des contraintes darchitecture ou des besoins de modularit et rutilisation. Bon les programmeurs C et COBOL, quand est ce que lon vous voit sur le forum UML !