Ch. 5 — Principes : modularité

Composer un logiciel en briques : paquetages, les cinq principes de modularité, les cinq règles de Bertrand Meyer et les quatre niveaux de visibilité en Java.

Composer des modules

Écrire un gros programme, c'est difficile — la modularité est la réponse : au lieu d'enchaîner des instructions, on compose des modules (des composants). Un module peut être :

une classe ;
un paquetage ;
une bibliothèque logicielle.

Un module, c'est une brique de fonctionnalité — et une abstraction de plus haut niveau : on raisonne « boîte à lettres », pas « quatre vis et un ressort ».

Les paquetages (package)

Un paquetage, c'est un regroupement logique de classes :

il organise le code en groupes cohérents (pensez à java.io, javafx.utils) ;
le paquetage anonyme (par défaut) existe mais ne doit pas être utilisé ;
il influe sur la visibilité des classes (voir plus bas).

package fr.univlille.map.buildings;
class Restaurant extends Building { ... }

package fr.univlille.map.streets;
class Street { ... }

Deux conventions au passage : les classes d'une même hiérarchie vivent souvent dans le même paquetage ; et le nommage suit le domaine inversé (fr.univlille.…) pour naviguer facilement et éviter les doublons entre équipes.

Un module peut être une classe, un paquetage ou une bibliothèque. Le nommage en domaine inversé (fr.univlille…) évite les doublons entre équipes — et le paquetage influe sur la visibilité des classes (niveau « default »).

Les 5 principes de modularité

Principe	« Capacité de… »
Décomposabilité modulaire	décomposer un problème en sous-problèmes
Composition modulaire	recombiner / réagencer des modules
Continuité modulaire	réduire l'impact d'un changement à un minimum de modules liés
Protection modulaire	limiter les effets d'un incident d'exécution à un minimum de modules liés
Compréhension modulaire	interpréter le fonctionnement d'un module sans connaître tout le logiciel

Les 5 règles de Bertrand Meyer

Règle	Énoncé
Mapping direct	une abstraction devrait correspondre à un modèle du monde réel
Couplage faible	chaque module communique avec le moins d'autres modules possible
Interface minimale	quand deux modules communiquent, l'échange d'information doit être minimal
Interface explicite	les informations échangées doivent être explicites dans le code de l'un ou des deux modules
Masquage de l'information	un sous-ensemble des propriétés d'un module est accessible aux clients, le reste (non vide) est caché

Le fil rouge

Ces règles recoupent tout le cours : le couplage faible, c'est le fil des patrons (Observer, Stratégie…) ; le masquage de l'information, c'est l'encapsulation — et les paquetages sont l'outil Java pour ça.

La visibilité en Java

Le langage offre quatre niveaux, du plus ouvert au plus fermé :

Les quatre niveaux de visibilité, du plus ouvert au plus fermé. Règle d'or du masquage de l'information : n'exposer que le nécessaire — le reste (non vide) reste caché.

Niveau	Accessible depuis
`public`	toutes les classes
`protected`	les classes du même paquetage et les sous-classes
(default) — rien d'écrit	les classes du même paquetage seulement
`private`	la classe elle-même seulement

Modularité, documentation et tests

Une bonne modularité, c'est aussi :

un code plus compréhensible, chaque module plus facile à documenter (surtout ses parties non privées) ;
un code plus testable et maintenable : chaque module éprouvé par des tests, sans devoir réécrire toute une panoplie de tests au moindre changement.

A retenir

écrire un gros programme est difficile : les notions clés sont l'abstraction et la modularité ;
les règles pour la modularité : mapping direct, couplage faible, interface minimale, interface explicite, masquage de l'information ;
en Java, ces règles se traduisent par les paquetages et les visibilités — exposer le moins possible, cacher le reste.

ch5-modularite.pdf

R3.04 · Cours 5 — Fabien Delecroix, base de Nicolas Anquetil · 20 diapositives

Consultation seule — téléchargement désactivé

Chargement du document…