Commençons par Wikipedia:
Plus formellement, la loi de Demeter pour les fonctions nécessite qu'une méthode
m forte> d'un objet o strud> ne peut appeler que les méthodes des types suivants d'objets: P >
- o elle-même li>
- Paramètres de M LI>
- Tous les objets créés / instanciés dans M LI>
- Os Direct Composant Objects LI>
- une variable globale, accessible par O, dans la portée de M LI> ol> blockQuote>
règle 1: p>
xxx pré> règle 2: p>
xxx pré> règle 3: p>
xxx pré> règle 4 (merci@juhararr): p>
xxx pré> règle 5: p>
xxx pré> Quelqu'un peut-il m'aider avec la règle 5? p>
et non la loi de Demeter implique que le chaînage est mauvais? P>
User.getName().getLastName();
3 Réponses :
"dire ne demande pas" est un peu différent.
Demeter: N'avez pas quelque chose pour faire quelque chose à partir de celui-ci pour faire quelque chose sur la dernière chose.
TDA: ne récupérez pas les "informations" d'un autre objet pour prendre une décision à ce sujet. Exemple simple: vs. dans les deux cas, vous appelez une méthode sur un autre objet; Mais il y a une différence clé: le premier appel expose "interne" de cet autre objet à vous; sur lequel vous prenez ensuite une certaine décision. ATTENDU QUE, dans la deuxième version "TDA"; vous laissez cette "évaluation de l'état" dans cet autre objet; En quelque sorte, réduisant ainsi le couplage. mais juste pour l'enregistrement: ce deuxième exemple toujours prend une décision basée sur l'état de cette liste. De ce point de vue, il s'agit simplement d'une meilleure version que l'option 1. Idéalement, vous n'auriez pas besoin de tels chèques.
Le 5ème est difficile à représenter dans C # ou Java, car ils ne soutiennent pas techniquement les variables globales. Cependant, dans un modèle de conception similaire en principe, vous pourriez avoir par exemple. une classe de configuration qui contient simplement des valeurs de configuration statiques accessibles à l'échelle mondiale, telles que (c #): dans ce cas (en supposant que le modèle de conception était acceptable de toutes les autres manières), la loi de Demeter permettrait cela, car il est globalement accessible et destiné à être ainsi.
Donc, le champ "myconfigurationValue" ne devrait-il pas être public?
@ROBIOW non dans cet exemple, car cela montre comment fournir des informations de configuration de manière globale, mais nous ne voulons pas que d'autres classes puissent la modifier, soit par accident, soit exprès. En règle générale, lorsque vous permettez à la fois de lire et de modifier les propriétés, la création d'un public est nécessaire (pour ceux qui favorisent l'approche «Propriété», je remarquerais que les propriétés sont surtout simplement une manière sournoise de pouvoir dire que tout Les variables des membres sont privées, même si elles agissent comme si elles sont publiques, par des méthodes qui ajoutent les frais généraux derrière les scènes pour les rendre publics).
Un exemple de règle 5 serait: Enums fonctionne essentiellement de cette façon, et il est correct d'accéder à Enums. P> Votre exemple: P>
reportBuilder.withMargin(5).withFooter(10)
.withBorder(Color.black).build();
La règle 4 est si
classone a un champ privé (composant) de typeclasstwo , vous pouvez appeler des méthodes sur ce champ à partir de votre méthode dansclassone .Je knwo ce Java est question, mais toutes les règles (y compris la règle 5) peut être définie Kotlin gist.github. Com / Panell / 5E1A75746B41F69CF6E2093388E100FC