Loi de Déméter — Wikipédia
![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/70/Hydrie_-_Myst%C3%A8res_d%27Eleusis_%28face_A%29.jpg/220px-Hydrie_-_Myst%C3%A8res_d%27Eleusis_%28face_A%29.jpg)
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 peut requérir un service (appeler une méthode) d'un objet , mais ne peut pas utiliser pour accéder à un troisième objet et requérir ses services. Faire cela signifierait que a une connaissance plus grande que nécessaire de la structure interne de . Au lieu de cela, pourrait être modifié si nécessaire pour que puisse faire la requête directement à , et propagera la requête au composant ou sous-composant approprié. Si la loi est appliquée, seul connait sa propre structure interne.
Plus formellement, la Loi de Déméter pour les fonctions requiert que toute méthode d'un objet peut simplement invoquer les méthodes des types suivants d'objets :
- lui-même
- les paramètres de
- les objets que crée/instancie
- les objets membres de
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
[modifier | modifier le code]- 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.