Editions ENI Livres | Vidéos | e-Formations
Conception orientée objet
L’avènement des objets
Désormais, les systèmes d’information orientés objet sont devenus extrêmement populaires dans les environnements de développement industriels ; à ce titre, on peut les considérer comme incontournables. En effet, comparées aux environnements traditionnels, les technologies objet (OT) permettent de délivrer sur le marché des produits de haute qualité, plus rapidement et à des coûts de maintenance moindres.
Selon Taylor et Jacobson (1995), les OT lient étroitement la technique et les affaires en offrant la possibilité de modéliser les objets métier (BO) de même que les processus métier (BP) - toujours à base d’objets.
L’objectif du présent chapitre est de fournir ou de rappeler à l’architecte ainsi qu’au développeur les principes éprouvés d’une solide conception orientée objet (COO).
1. Quelles sont les différences ?
Par rapport aux technologies traditionnelles, on peut identifier dans la COO un certain nombre d’évolutions qui ont largement contribué à son adoption massive :
-
La réutilisabilité.
-
Un cycle de vie itératif.
-
La structuration du système en sous-systèmes, composants, paquetages et classes.
-
Un haut niveau d’abstraction.
-
Des structures...
Principes élémentaires
La qualité d’un logiciel ne se mesure pas qu’à la validation des tests plans par l’équipe de qualification. En termes de qualité OO, l’architecte dispose de trois piliers sur lesquels il doit s’appuyer lors de ses phases de conception. Il s’agit de l’encapsulation, du couplage et de la cohésion : on juge généralement bon un design qui maximise l’encapsulation et fait apparaître un couplage faible ainsi qu’une forte cohésion de ses classes et de ses modules, ce qui induit un système facile à étendre et à maintenir.
On verra au cours du chapitre Boîte à outils - section Métrologie qu’on peut mettre en place des outils de mesure de la cohésion et du couplage d’un système.
1. Encapsulation
L’idée de l’encapsulation est de n’exposer d’un composant que ce qui est nécessaire aux autres pour l’utiliser. Autrement dit, on doit pouvoir utiliser un objet sans en connaître le fonctionnement interne.
a. Comment l’appliquer ?
On gère l’encapsulation en définissant la visibilité des attributs et des opérations à l’extérieur de la classe. Les langages OO offrent généralement le choix entre public (visible par tous), protected (visible seulement...
Principes avancés
Cette section décrit six principes de conception OO, éprouvés et désormais célèbres, qu’on utilise (le plus souvent sans le savoir) dès qu’on a un peu d’expérience en conception orientée objet.
1. Responsabilité unique (SRP)
Il s’agit d’un principe fondamental, énoncé par De Marco et Meilir Page-Jones, qu’ils avaient à l’époque dénommé principe de cohésion :
Il ne devrait pas y avoir plus d’une raison pour une classe de changer.
Le principe de responsabilité unique induit que chaque classe du système doit avoir une seule responsabilité bien identifiée. Dans le cas contraire, il y aurait un couplage des responsabilités qui conduirait à une architecture fragile et provoquerait des effets de bord inattendus.
Les exigences fonctionnelles, de nature très versatiles, sont associées à des classes métier. Quand ces exigences évoluent, ce changement se manifeste par une modification de responsabilité des classes et, si une classe assume plus d’une responsabilité, elle a alors plus d’une raison de changer.
Ce principe n’a que des avantages, il produit un code plus lisible, plus robuste et plus facile à maintenir car, les responsabilités étant clairement identifiées, la chasse aux défauts en sera d’autant facilitée.
a. Comment l’appliquer ?
Lorsqu’on détecte qu’une classe représente plus d’une abstraction, elle doit être refactorisée en autant de classes que d’abstractions uniques.
Modélisation métier
Le plus simple pour mettre en place ce principe est d’y recourir dès la phase d’analyse du processus itératif. Par exemple, dans la méthode Iconix que nous avons précédemment abordée, lorsqu’on modélise les objets du domaine (ou classes métier), il convient de passer en revue chacune des classes pour s’assurer qu’elle ne dessert qu’un seul et unique objectif.
Nommage
Le nommage des classes et des méthodes est ici de toute première importance, il doit refléter la responsabilité et le comportement des classes. Un nommage explicite facilite...
Conclusion
Tous ces principes, sous leur apparente simplicité, peuvent s’avérer subtils, surtout pour le néophyte. Ils se révèlent parfois difficiles à appliquer dans un projet pour des raisons de planning trop serré ou de coût prohibitif. En prenant la décision de s’affranchir d’un bon principe de conception (qui a nécessairement un coût), le chef de projet devra évaluer avec l’architecte la pertinence de réaliser à court terme des économies qui pourraient engager des dépenses imprévues par la suite, si le design dérive. Quelquefois on n’applique pas ces principes car il faut du temps et de l’expérience pour les maîtriser ; c’est là que l’architecte doit jouer son rôle d’évangélisateur auprès des équipes de développement, lors des revues de code qu’il devrait solliciter régulièrement. Dans d’autres cas, les appliquer avec trop de zèle rendrait l’architecture inutilement complexe. Pour finir, il va de soi que ces bonnes pratiques vont de pair avec un développement itératif, une sérieuse couverture fonctionnelle par des tests automatisés et une pratique assidue de la refactorisation.
Un bon design ne provient jamais d’une création ex nihilo, mais d’un long...
