Architecture orientée objet

L'architecture orientée objet (OOA) désigne la structure globale d'un système logiciel conçu selon les principes de la POO.

Elle organise :

• Les objets et classes du système
• Les relations entre ces objets
• Les comportements encapsulés dans les objets

L'objectif est de construire un logiciel modulaire, maintenable, évolutif et cohérent avec le monde réel.

Contrairement à une architecture procédurale, où le programme est une succession de fonctions, l'architecture orientée objet organise les entités logicielles autour de concepts réels.

Objectifs principaux de l'architecture orientée objet

• Modéliser le monde réel : Chaque objet représente une entité identifiable avec des propriétés et des comportements.
• Réutilisation du code : Grâce à l'héritage, aux interfaces et aux design patterns.
• Isolation et encapsulation : Chaque objet contrôle ses données et expose uniquement ce qui est nécessaire.
• Évolutivité et maintenance : Il est plus facile de remplacer, modifier ou ajouter des composantes sans casser le système.
• Communication claire : L'architecture facilite la collaboration entre développeurs et équipes.

Principes fondamentaux de l'architecture orientée objet

Encapsulation

• Les données et comportements d'un objet sont regroupés.
• On protège l'état interne des modifications directes.

Abstraction

• On expose uniquement les comportements pertinents.
• Les détails d'implémentation restent cachés.

Héritage

• Permet de créer de nouvelles classes à partir de classes existantes.
• Facilite la réutilisation et la factorisation du code.

Polymorphisme

• Permet d'utiliser un objet via son interface, indépendamment de sa classe concrète.
• Facilite les architectures flexibles et évolutives.

Principes SOLID

Ces principes orientent la conception d'une architecture robuste et maintenable.

Composantes typiques d'une architecture orientée objet

Classes et objets

• Classes : définitions de types et comportements
• Objets : instances concrètes avec état propre

Paquets et modules

• Groupent des classes et interfaces selon des responsabilités communes
• Favorisent la modularité et la lisibilité

Interfaces et abstractions

• Définissent des contrats pour les interactions entre objets
• Séparent le "quoi" du "comment"

Relations entre classes

• Association : relation simple (un objet connaît un autre)
• Agrégation / composition : "has-a" (un objet contient d'autres objets)
• Héritage : "is-a" (une classe est un type d'une autre classe)

Modèles architecturaux orientés objet

Architecture en couches (Layered)

• Présentation : interface utilisateur
• Métier / logique : règles métier, objets du domaine
• Données / persistence : accès aux bases de données
• Les couches communiquent via des interfaces

MVC (Model-View-Controller)

• Model : objets métiers et données
• View : affichage et interface utilisateur
• Controller : coordination des actions et mise à jour du modèle

Architecture hexagonale (Ports & Adapters)

• Les objets métiers restent isolés du monde extérieur
• Les interfaces (ports) permettent d'adapter les objets à différentes technologies

Bonnes pratiques de conception d'architecture orientée objet

• Respecter les responsabilités uniques (SRP) : Chaque classe doit avoir une seule responsabilité.
• Favoriser la composition sur l'héritage : Préférer "has-a" plutôt que "is-a" si possible.
• Programmer contre des abstractions : Les objets interagissent via des interfaces et non via des classes concrètes.
• Utiliser des design patterns judicieusement : Exemple : Strategy, Observer, Factory, Singleton.
• Découpler les modules : Limiter les dépendances pour faciliter la maintenance.
• Documenter les objets et leurs relations : UML ou diagrammes de classes aident à visualiser l'architecture.

Exemple d'architecture orientée objet simple

Contexte : gestion d'une bibliothèque

• Objets principaux : Livre, Membre, Emprunt
• Relations :
• Un Membre peut avoir plusieurs Emprunts
• Chaque Emprunt concerne un Livre
• Interfaces : IEmpruntable (tout objet pouvant être emprunté)
1. Type
2.  ILivre=Interface
3.   Procedure AfficherTitre;
4.  End;
5.  
6.  TLivre = class(TInterfacedObject, ILivre)
7.   Titre:String;
8.   Procedure AfficherTitre;
9.  End;
10.  
11.  TMembre=Class
12.   Nom:String;
13.   Emprunts:Array of TLivre;
14.   Procedure Emprunter(L: TLivre);
15.  End;


• L'architecture permet d'ajouter facilement un CD, DVD ou magazine implémentant IEmpruntable sans modifier les autres objets.

Outils pour modéliser l'architecture orientée objet

• UML (Unified Modeling Language)
• Diagrammes de classes
• Diagrammes de séquence
• Diagrammes de paquets
• Outils pratiques : StarUML, Enterprise Architect, Visual Paradigm, ArgoUML

Avantages de l'architecture orientée objet

• Meilleure maintenabilité et évolutivité
• Code plus lisible et compréhensible
• Favorise la réutilisation grâce aux classes et interfaces
• Permet d'appliquer facilement SOLID et les Design Patterns
• Facilite les tests unitaires et la modularité

Limites et précautions

• Risque de sur-conception si on applique trop d'abstractions
• Complexité accrue pour des petits projets simples
• Nécessite une bonne compréhension des principes POO

Conclusion

L'architecture orientée objet est la fondation pour construire des logiciels robustes et évolutifs. En combinant classes, objets, héritage, interfaces, design patterns et principes SOLID, on obtient un système clair, modulable et facile à maintenir.

Règle d'or : modéliser avant de coder, et utiliser les abstractions pour isoler la complexité.