Loi de Déméter

Ce tutoriel vous donne une brève explication de la loi de Déméter . Il est basé sur une ébauche de chapitre pour mon prochain livre "The Art of Clean Code" à apparaître avec NoStarch en 2022.

L'art du code propre

La plupart des développeurs de logiciels perdent des milliers d'heures à travailler avec du code trop complexe. Les huit principes fondamentaux de The Art of Clean Coding vous apprendront à écrire un code clair et maintenable sans compromettre les fonctionnalités. Le principe directeur du livre est la simplicité :réduisez et simplifiez, puis réinvestissez de l'énergie dans les parties importantes pour vous faire gagner d'innombrables heures et faciliter la tâche souvent onéreuse de maintenance du code.

1. Concentrez-vous sur l'essentiel avec le principe 80/20 — concentrez-vous sur les 20 % de votre code qui comptent le plus
2. Évitez de coder de manière isolée :créez un produit minimum viable pour obtenir des commentaires rapides
3. Écrivez le code proprement et simplement pour éliminer l'encombrement
4. Éviter une optimisation prématurée qui risque de trop compliquer le code
5. Équilibrez vos objectifs, vos capacités et vos commentaires pour atteindre l'état productif de Flow
6. Appliquez le bien faire une chose philosophie pour améliorer considérablement la fonctionnalité
7. Concevez des interfaces utilisateur efficaces avec Moins c'est plus principe
8. Regroupez vos nouvelles compétences en un seul principe unificateur :Concentrez-vous

L'art du codage propre basé sur Python convient aux programmeurs de tous niveaux, avec des idées présentées de manière indépendante du langage.

Aperçu

Vous avez déjà appris que l'une des raisons les plus importantes de la complexité du code est l'interdépendance. Pour écrire du code propre, vous devez minimiser le degré d'interdépendance de vos éléments de code.

Les dépendances sont partout. Si vous importez un module ou une bibliothèque dans votre code, votre code dépend en partie des fonctionnalités fournies par la bibliothèque. Mais votre code ne dépendra pas uniquement de sources externes. Il existe également de nombreuses interdépendances dans votre code. Si vous utilisez la programmation orientée objet, une fonction peut dépendre d'une autre fonction, un objet peut dépendre d'un autre objet et une définition de classe d'une autre définition de classe.

La loi de Déméter stipule que vous "ne parlez qu'à vos amis immédiats" . Le but de la loi est de minimiser le nombre de dépendances entre vos objets de code. Chaque objet appelle uniquement ses propres méthodes ou méthodes à partir d'objets "voisins immédiats" - il n'appelle pas les méthodes des objets qu'il obtient en appelant une méthode.

Cela peut sembler déroutant au début, alors plongeons-nous dans un exemple pratique. Sans la loi de Déméter, les trois objets connaissent tous les autres objets. Avec la loi de Déméter, l'objet Personne ne connaît qu'un seul autre objet et ne se soucie pas de l'autre. Cela dissocie les définitions de classe, réduit la complexité et augmente la maintenabilité de votre code.

Figure  :Loi de déméter :ne parlez qu'à vos amis pour minimiser les dépendances.

La figure montre deux projets de code orienté objet où votre objectif est de calculer le prix par tasse de café pour une personne donnée. Vous créez une méthode price_per_cup() qui utilise l'objet CoffeeCup actuel pour collecter plus d'informations sur le prix de la machine à café qui a produit le café dans la tasse. Cette information est pertinente pour calculer le prix par tasse. Une mauvaise stratégie est donnée à gauche :

1. La méthode price_per_cup() appelle la méthode CoffeeCup.get_creator_machine() pour obtenir une référence à l'objet de la machine à café qui a créé le café.
2. La méthode get_creator_machine() renvoie une référence d'objet à la machine à café qui a produit son contenu.
3. La méthode price_per_cup() appelle la méthode CoffeeMachine.get_price() sur le CoffeeMachine objet qu'il vient d'obtenir du précédent CoffeeCup appel de méthode.
4. La méthode get_price() renvoie le prix d'origine de la machine.
5. La méthode price_per_cup() calcule la dépréciation par tasse et l'utilise pour estimer le prix d'une seule tasse. Ceci est renvoyé à l'appelant de la méthode.

Pourquoi cette stratégie est-elle mauvaise ?

La raison est que la classe Person dépend de deux objets :CoffeeCup et CoffeeMachine. Un programmeur responsable de la maintenance de cette classe doit connaître les deux définitions de classes dépendantes. Tout changement dans l'une de ces classes peut également avoir un impact sur cette classe.

La loi de Déméter vise à minimiser ces dépendances. Vous pouvez voir une meilleure façon de modéliser le même problème sur la droite de la figure.

1. La méthode price_per_cup() appelle la méthode CoffeeCup.get_costs_per_cup() pour obtenir le prix estimé par tasse en fonction des informations de la tasse de café.
2. La méthode get_costs_per_cup() —avant de répondre à la méthode appelante—appelle la méthode CoffeeMachine.get_price() pour accéder aux informations de tarification souhaitées pour l'ensemble de la machine.
3. La méthode get_price() renvoie les informations sur le prix.
4. La méthode get_costs_per_cup() calcule le prix par tasse et le renvoie à la méthode appelante price_per_cup() .
5. La méthode price_per_cup() transmet simplement cette valeur calculée à son appelant.

Pourquoi est-ce supérieur à la première approche ? La raison est que la classe Person est maintenant indépendant de la classe CoffeeMachine . Le nombre total de dépendances a diminué.

En protégeant la complexité du programmeur du Person classe, vous lui avez rendu la vie beaucoup plus facile. Si vous avez un projet avec des centaines de classes et que vous réduisez les dépendances grâce à l'application de la loi de Demeter, vous pouvez réduire considérablement la complexité globale de votre application car le nombre de dépendances potentielles augmente de manière super linéaire avec le nombre d'objets. Cela signifie également que la loi de Demeter a le potentiel de réduire le nombre de dépendances de manière super-linéaire dans le nombre d'objets impliqués !