Le couplage, la cohésion et la loi de Demeter

Question

La Loi de Déméter indique que vous ne devez parler à des objets que vous connaissez directement. C'est, ne pas effectuer la méthode de chaînage de parler à d'autres objets. Lorsque vous procédez ainsi, vous établissez une mauvaise liens avec l'intermédiaire des objets, de façon inappropriée couplage votre code à l'autre code.

C'est un mauvais.

La solution serait pour la classe que vous savez à propos de l'essentiel de l'exposer simples emballages qui en déléguer la responsabilité à l'objet de la relation.

Ce qui est bon.

Mais, qui semble résulter de la classe ayant un faible cohésion. Elle n'est plus seulement responsable pour précisément ce qu'il fait, mais il a aussi les délégués que dans un sens, rendre le code moins cohésive en dupliquant des parties de l'interface de l'objet associé.

C'est un mauvais.

Est-il vraiment baisser la cohésion? C'est le moindre de deux maux?

Est-ce l'une de ces zones grises de développement, où vous pouvez débat où la ligne est, ou il y a de forte, fondée sur des principes façons de rendre une décision de l'endroit où tracer la ligne et quels sont les critères que vous pouvez utiliser pour prendre cette décision?

Answer 1

Grady Booch dans "Analyse Orientée Objet et Design":

"L'idée de la cohésion provient également de la conception structurée. Simplement dit, la cohésion mesure le degré de connectivité entre les éléments d'un module unique (et pour la conception orientée objet, une seule classe ou d'un objet). La moins souhaitable forme de la cohésion est une coïncidence de cohésion, totalement sans rapport avec les abstractions sont jetés dans la même classe ou d'un module. Par exemple, considérons une classe comprenant les abstractions des chiens et des vaisseaux spatiaux, dont les comportements sont tout à fait indépendants. L' plus souhaitable forme de cohésion est la cohésion fonctionnelle, dans laquelle les éléments de une classe ou d'un module de travailler tous ensemble pour fournir certains bien délimité comportement. Ainsi, la classe Chien est fonctionnellement cohérent si sa sémantique embrasser le comportement d'un chien, l'ensemble de chien, et rien que le chien".

Suppléant Chien avec le Client dans le ci-dessus et il pourrait être un peu plus clair. Donc, le but est vraiment juste pour objectif de cohésion fonctionnelle et à s'éloigner de la coïncidence de la cohésion autant que possible. En fonction de votre abstractions, cela peut être simple ou peut nécessiter quelques refactorisation.

Note de cohésion s'applique tout autant à un "module" qu'à une seule classe, c'est à dire un groupe de travail en classe ensemble. Donc, dans ce cas, le Client et l'Ordre classes ont encore décent de cohésion à cause de cette forte relationshhip, aux clients de créer des ordres, des ordres appartiennent à des clients.

Martin Fowler dit qu'il serait plus à l'aise à l'appeler le "Suggestion de Déméter" (voir l'article se moque de ne stubs):

"Mockist testeurs ne parlons plus de prévenir le "déraillement" de la méthode des chaînes de style de get: ().getThat().getTheOther(). En évitant la méthode des chaînes est également connu comme la suite de la Loi de Déméter. Alors que la méthode des chaînes d'une odeur, le problème inverse de la moyenne des hommes objets de ballonnement de l'envoi des méthodes est aussi une odeur. (J'ai toujours senti que je serais plus à l'aise avec la Loi de Déméter s'il était appelé à la Suggestion de Déméter .)"

Qui résume bien où je veux en venir: il est parfaitement acceptable et souvent nécessaire d'avoir un plus faible niveau de cohésion que le strict respect de la "loi". Éviter la coïncidence de la cohésion et de l'objectif de cohésion fonctionnelle, mais ne vous attardez sur les aspects en cas de besoin pour s'adapter au plus naturellement avec votre conception de l'abstraction.

Answer 2

Si vous êtes en violation de la Loi de Déméter en ayant

int price = customer.getOrder().getPrice();

la solution n'est pas de créer un getOrderPrice() et de transformer le code en

int price = customer.getOrderPrice();

mais au lieu de noter que c'est une odeur de code et de faire les changements que l'on espère à la fois de renforcer la cohésion et la plus faible couplage. Malheureusement, il n'est pas simple ici que s'applique toujours, mais vous devriez probablement s'appliquer dire de ne pas poser de

Answer 3

Je pense que vous avez peut-être mal compris ce que la cohésion signifie. Une classe qui est mis en œuvre en termes de plusieurs autres classes n'ont pas nécessairement de faible cohésion, tant qu'il représente un concept clair, et un objectif clair. Par exemple, vous pouvez avoir un class Person, ce qui est mis en œuvre en termes de classes d' Date (pour la date de naissance, Address, et Education (une liste des écoles de la personne est allée à l'). Vous pouvez fournir de l'encapsulation en Person pour arriver à l'année de naissance, la dernière école la personne est allée à, ou de l'état où il vit, pour éviter d'exposer le fait qu' Person est mis en œuvre en termes de ceux des autres classes. Cela permettrait de réduire le couplage, mais il ferait Person pas moins cohérent.

Answer 4

C'est une zone grise. Ces principes sont destinés à vous aider dans votre travail, si vous trouvez que vous travaillez pour eux (c'est-à-dire qu'ils vous gênent et / ou que vous trouvez que cela complique votre code), alors vous vous conformez trop et vous avez besoin reculer.

Faites-le fonctionner pour vous, ne le faites pas.

Answer 5

Dans les situations où il semble y avoir un compromis entre couplage et cohésion, je me demanderais probablement "si quelqu'un d'autre avait déjà écrit cette logique et que je cherchais un bug, où chercherais-je en premier?", Et écrivez le code de cette façon.