Pourquoi faire des efforts de conception ?

Il faut avoir en tête la seule constante du développement : le changement !

De nombreux événements conduiront à modifier le code d'une application :

• Modification des fonctionnalités et modèles
• Augmentation du nombre d'utilisateurs et des volumes de données
• Obsolescence des outils (bibliothèques, frameworks, services tiers…)
• Changement de cible (desktop, serveur, mobile, cloud…)
• Choix politique (base de données, OpenSource…)

Les patrons de conception dans tout ça ?

Ce cours s'inspire de « Design patterns : tête la première » d'Eric Freeman et Kathy Sierra. Nous verrons :

• Les prérequis pour comprendre l'intérêt des patrons de conception : La programmation orientée objet (POO) et les principes de conception
• Les mauvaises pratiques à travers les anti-patrons
• Les bonnes pratiques avec les principaux patrons de conception (TP)
• Quelques patrons architecturaux

Un paradigme omniprésent

De nombreux programmeurs manipulent des objets sans forcément en avoir conscience :

• En appelant chaine.upper() pour transformer une chaîne de caractères en majuscules, nous faisons appel à la notation pointée typique de la POO
• En Python, tout est objet :

Un paradigme difficile à maîtriser

Utiliser des classes existantes demandera peu d'effort. Il sera plus délicat de concevoir proprement ses propres classes :

• Répartir les responsabilités entre les classes
• Choisir les bonnes relations (héritage, composition…)
• Faciliter les évolutions sans tout réécrire

Spoiler : c'est précisément l'objet des principes de conception et des patrons de conception que nous verrons par la suite !

Des concepts à comprendre

Les concepts de classe, d'attribut et d'héritage sont généralement bien maîtrisés pour modéliser des données (objet de domaine).

Il convient toutefois de bien comprendre l'intérêt des autres concepts de la POO pour modéliser des traitements :

• Se protéger contre des erreurs de programmation (ex : visibilité, encapsulation)
• S'assurer d'être en mesure de modifier le code sans casser les appels
• Pouvoir tester unitairement les fonctionnalités (en bouchonnant les autres à l'aide de « mock »)

→ Méditons quelques exemples

Une conception à adapter au langage (1/3)

Les langages qui permettent de définir et manipuler les concepts de base de la POO sont nombreux (Java, JavaScript (ES6), TypeScript, C++, Python, PHP…).

Ce cours s'appuiera sur des exemples et TP en TypeScript, en se concentrant sur ce qui est applicable à de nombreux langages.

Une conception à adapter au langage (2/3)

Comme l'illustre la difficulté de faire ce choix, les langages ont des spécificités qui devront être prises en compte et exploitées dans la conception, en particulier :

• Le typage statique ou dynamique (vérification des types à la compilation ou à l'exécution)
• La signature des méthodes (surcharge possible ou unicité des noms)
• La gestion de la mémoire (ramasse-miettes, comptage de références, libération manuelle, notion de propriété (Rust)…)
• La présence de concepts complémentaires (propriétés, annotations…) et de patrons intégrés (Iterator, Prototype…)

Une conception à adapter au langage (3/3)

Aussi, la plupart des langages sont désormais multi-paradigmes (Python, JavaScript, PHP, C++…). Il faudra parfois choisir entre la définition d'une classe et celle d'une simple fonction.

Dans ce cours, nous nous concentrerons sur des approches purement POO, mais vous constaterez qu'il est possible de mixer les paradigmes :

const nombreUtilisateursMajeurs = userRepo.getUsers() // POO
  .filter(user => user.age >= 18) // programmation fonctionnelle
  .length;

SOLID

Nous allons commencer par 5 principes fondamentaux regroupés dans l'acronyme SOLID :

• Single Responsibility Principle (SRP, responsabilité unique)
• Open Closed Principle (OCP, ouvert/fermé)
• Liskov Substitution Principle (LSP, substitution de Liskov)
• Interface Segregation Principle (ISP, ségrégation des interfaces)
• Dependency Inversion Principle (DIP, inversion des dépendances)

Principe d'exposition minimale

Il convient d'exposer un minimum de fonctionnalités au niveau d'une classe (i.e. de maximiser l'encapsulation).

En pratique, quand le langage le permet (PHP, Java, C++, TypeScript…) :

• Les méthodes et attributs sont privés par défaut
• Les accesseurs sont définis uniquement si c'est nécessaire (traitement.getLogger())
• Une méthode spécifique est préférée à un accesseur permettant de nombreuses opérations
  • Les collections sont encapsulées (obj.points.add(p) → obj.addPoint(p))

Identifier et encapsuler ce qui varie (1/3)

Cas d'école : j'identifie le besoin de produire des journaux applicatifs (logs) plus ou moins détaillés…

class MaClasse {

    faireUnTruc(){
        console.log("Je fais un truc");
        // ...
    }

}

Préférer la composition à l'héritage (2/2)

Pourquoi ? Notez dans un premier temps que :

• L'héritage est une relation plus forte que la composition (il est donc plus difficile de s'en libérer)
• Si vous développez un formulaire, modifier un type (affectation) est plus simple que transformer un Chien en Chat (construction)

Spoiler : nous verrons plus tard avec les patrons Template Method et Strategy en quoi la composition est préférable à la surcharge d'une méthode pour faire varier le comportement d'une classe.

Principe des anti-patrons

• Nommer des erreurs de conception classiques
• Faciliter l'identification des erreurs de conception

Réinventer la roue carrée

Ne pas s'appuyer sur une solution existante.

Par exemple :

• Développer son propre système pour l'écriture des journaux applicatifs
• Développer son propre système d'exécution de tests unitaires

Programmation spaghetti

Le rôle des différents éléments du système n'est pas identifiable et il est difficile de savoir qui appelle qui.

En conséquence, il est difficile de :

• Modifier une partie du code sans en altérer le fonctionnement
• Trouver la cause d'un bug

Spoiler : nous verrons que les patrons architecturaux amènent un cadre permettant d'éviter ce problème.

Objet divin

L'objet divin porte un trop grand nombre de responsabilités.

Il est en violation flagrante du principe de responsabilité unique (SRP).

Abstraction inverse

Un composant ne fournit pas les abstractions nécessaires, mais seulement les méthodes les plus compliquées.

Les abstractions sont développées dans les clients.

Spoiler : nous verrons comment le patron façade permet d'y remédier.

Marteau doré

Avec un bon marteau, tous les problèmes sont des clous ! Un outil est placé comme solution à tous les problèmes.

(Source engravingawardsgifts.com)

Il peut s'agir d'une bibliothèque, d'une base de données, d'une suite de logiciels, etc.

Coulée de lave

Un code non finalisé est mis en production. Il n'est plus possible de le remanier.

Ce problème pourra concerner aussi bien des bibliothèques que des API WEB ou en ligne de commande (CLI). Il conviendra de considérer que livrer revient à figer les interfaces publiques.

Spoiler : il est possible de traiter les changements en gérant proprement des versions (voir mborne.github.io - Le refactoring).

Définition

Le concept de patron de conception a été défini par le « Gang of Four » (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides) dans le livre « Design Patterns — Elements of Reusable Object-Oriented Software » (1994).

Un patron de conception est la description d'une solution réutilisable pour un problème de conception.

Formalisme des patrons de conception

Ces patrons obéiront au formalisme suivant :

• Un nom
• Un problème
• Une solution
• Des conséquences (avantages et inconvénients)

Familles de patrons de conception du GoF

Le « Gang of Four » définit trois familles de patrons de conception :

• Les patrons de création (creational patterns) qui décrivent des techniques d'initialisation des objets
• Les patrons de structure (structural patterns) qui décrivent des organisations classiques de classes
• Les patrons de comportement (behavioral patterns) qui décrivent des méthodes de communication entre objets

Autres familles de patrons de conception

Le concept de patron sera étendu par la suite et nous trouverons en complément :

• Des patrons architecturaux qui traitent des styles d'architecture de logiciel (MVC, micro-service…)
• Des familles de patrons spécifiques à des domaines d'application (cloud, big-data…)
• Des familles de patrons spécifiques à des frameworks (Spring…)

Intérêts des patrons de conception (1/2)

Les patrons de conception permettront de :

• Faciliter la compréhension des codes par l'utilisation d'un vocabulaire commun (*Builder, *Factory, addChild…)
• Faciliter la découverte du code et la compréhension des architectures en standardisant celles-ci (MVC, IoC, MQ…)
• Trouver de l'inspiration dans la recherche d'une solution :
  • Comment implémenter un interpréteur ? un annuler/refaire ?
  • Existe-t-il un framework MVC avec injection de dépendance pour ce langage ?

Intérêts des patrons de conception (2/2)

En particulier, la connaissance des patrons facilitera l'apprentissage et la découverte des bibliothèques et frameworks orientés objets.

Pour faire simple, sans connaissance des patrons, certains choix de conception sembleront inutilement complexes et il sera difficile de trouver comment initialiser les objets.