Loi de Déméter

La Loi de Déméter est nommée en référence aux mystères d'Eleusis.[réf. nécessaire]

La loi de Déméter (en anglais Law of Demeter ou LoD), ou Principe de connaissance minimale, est une règle de conception pour développer un logiciel, particulièrement du logiciel orienté objet. Cette règle a été inventée à la Northeastern University à Boston durant l'automne 1987, et peut être résumée en « Ne parlez qu'à vos amis immédiats ». La notion fondamentale est qu'un objet devrait faire aussi peu d'hypothèses que possible à propos de la structure de quoi que ce soit d'autre, y compris ses propres sous-composants.

Cette loi tient son nom du Projet Demeter, un effort de programmation adaptative et de programmation orientée objet. Ce projet a été nommé en l'honneur de Déméter, la déesse généreuse de l'agriculture dans la mythologie grecque, pour faire référence à une approche ascendante de la programmation que reflète aussi cette loi.

Appliquée à la programmation orientée objet, la loi de Déméter peut être appelée plus précisément la loi de Déméter pour les fonctions et les méthodes (sigle anglais : LoD-F). Dans ce cas, un objet A {\displaystyle A} peut requérir un service (appeler une méthode) d'un objet B {\displaystyle B} , mais A {\displaystyle A} ne peut pas utiliser B {\displaystyle B} pour accéder à un troisième objet et requérir ses services. Faire cela signifierait que A {\displaystyle A} a une connaissance plus grande que nécessaire de la structure interne de B {\displaystyle B} . Au lieu de cela, B {\displaystyle B} pourrait être modifié si nécessaire pour que A {\displaystyle A} puisse faire la requête directement à B {\displaystyle B} , et B {\displaystyle B} propagera la requête au composant ou sous-composant approprié. Si la loi est appliquée, seul B {\displaystyle B} connait sa propre structure interne.

Plus formellement, la Loi de Déméter pour les fonctions requiert que toute méthode M {\displaystyle M} d'un objet O {\displaystyle O} peut simplement invoquer les méthodes des types suivants d'objets :

  1. O {\displaystyle O} lui-même
  2. les paramètres de M {\displaystyle M}
  3. les objets que M {\displaystyle M} crée/instancie
  4. les objets membres de O {\displaystyle O}

En particulier, un objet doit éviter d'invoquer des méthodes d'un membre objet retourné par une autre méthode.

L'avantage de suivre la règle de Déméter est que le logiciel résultat est plus maintenable et plus adaptable. Puisque les objets sont moins dépendants de la structure interne des autres objets, ceux-ci peuvent être changés sans changer le code de leurs appelants. Un désavantage de la règle de Déméter est qu'elle requiert l'écriture d'un grand nombre de petites méthodes "wrapper" pour propager les appels de méthodes à leurs composants. Cela peut augmenter le temps de développement initial, accroître l'espace mémoire utilisé, et notablement diminuer les performances. Des outils automatiques peuvent partiellement contrecarrer ces problèmes. Basili et al. ont publié des résultats expérimentaux en 1996 suggérant que la loi de Déméter réduit la probabilité d'erreurs logicielles.

Littérature

  • V. Basili, L. Briand, W.L. Melo: A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering. October 1996. pp. 751-761. Vol. 22, Number 10.
  • Karl J. Lieberherr, I. Holland: Assuring good style for object-oriented programs. IEEE Software, September 1989, pp 38-48.
  • Karl J. Lieberherr: Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing Company, International Thomson Publishing, Boston, 1995.

Liens externes

  • (en) Law of Demeter (Web site)
  • (en) Object-Oriented Programming: An Objective Sense of Style (OOPSLA '88 Proceedings) (PDF)
v · m
Gestion de la qualité logicielle
Indicateurs de qualité (ISO/CEI 9126)
  • Capacité fonctionnelle (réponse aux exigences)
  • Fiabilité
  • Maintenabilité
  • Performance
  • Portabilité
  • Utilisabilité
Compréhension et contrôle du code source
Tests
Métriques
Remaniements
Principes de programmation
SOLID
Mauvaises pratiques
Antipatterns
Code smells
Voir aussi : Génie logiciel, Érosion de l'architecture logicielle
  • icône décorative Portail de la programmation informatique