Comment la loi de Demeter s'applique-t-elle aux systèmes orientés objet concernant le couplage et la cohésion? [fermé]

Comment la loi de Demeter s'applique-t-elle aux systèmes orientés objet avec couplage et cohésion?

Je lisais un livre "Développement de logiciels et pratique professionnelle" et suis tombé sur le chapitre sur LoD, et j'étais curieux de savoir comment ce principe est appliqué dans les systèmes orientés objet.

Selon Emerson Macedo, la loi de Déméter stipule ce qui suit:

• Chaque unité ne devrait avoir qu'une connaissance limitée des autres unités: seules les unités "étroitement" liées à l'unité actuelle.
• Chaque unité ne devrait parler qu'à ses amis; ne parlez pas à des étrangers.
• Ne parlez qu'à vos amis immédiats.

Cela correspond directement au principe du faible couplage car les unités (ou objets) sont censées le faire, un peu comme ci-dessus:

• Ne pas être étroitement couplés les uns aux autres. Seuls les plus proches le sont.
• Chacun ne doit parler qu'à ses collaborateurs et non aux collaborateurs du collaborateur
• Ne parler qu'à un objet collaborateur immédiat

L'une des formes de couplage les plus faibles est le passage de messages, c'est-à-dire que les données sont partagées entre les objets via des appels de méthode avec des paramètres.

De plus, d'après ce que je peux voir, la loi de Déméter ne correspond pas directement au principe de haute cohésion car elle stipule seulement que les objets eux-mêmes devraient savoir quelles données ils possèdent eux-mêmes. Un objet à faible cohésion possède des membres de données qu'il n'utilise pas fréquemment dans ses propres méthodes. Il s'agit davantage du contenu d'un objet que de ses relations et des objets collaborateurs.

Accouplement, simplifié

Lorsqu'un objet appelle une méthode, une propriété, etc. d'un autre objet, nous disons que les objets sont couplés. Nous l' appelons couplage parce que maintenant le callee ne peut pas changer quoi que ce soit au sujet de sa propre méthode / prop. sans casser l' appelant .

Ainsi, plus le couplage - méthodes, accessoires. - plus il est difficile de changer le code appelé sans casser tout le code qui l'utilise.

envisager le couplage

• Référençant même un seul accessoire, la méthode couple deux objets.
• Il est évident que le couplage est nécessaire pour créer un logiciel.
• Étant donné la nature du «verrouillage» du couplage, nous voulons à la fois le limiter et l'isoler. Cet objectif va de pair avec le développement logiciel général. des principes.
• Moins nous devons parler d'objets, plus le couplage est faible.
• Si j'ai besoin de faire, disons, 20 appels de méthode différents, le couplage est plus faible si tous les 20 appels sont à une classe / objet, vice versa ces mêmes méthodes réparties sur plusieurs classes / objets.

La plupart des connaissances provoquent un couplage fou

Ici, nous avons un Employeequi a un Personqui a une «adresse»

public class Employee {
    public Person me = new Person();
}
public class Person {
    public Address home = new Address();
}
public class Address {
    public string street;
} 

Pour obtenir la rue , je dois appeler: myEmployee.me.home.street. C'est à 180 degrés à l'opposé du principe de moindre connaissance. Je dois savoir sur le fonctionnement interne, la structure composite, du Employee, PersonetAddress les classes.

Cette conception de classe défectueuse me force à connaître toutes ces classes et doncmyEmployee.me.home.street me couple (l'objet appelant) à pas moins de 3 classes - pour obtenir une seule propriété!

La moindre connaissance sauve la mise

Si je parle à la seule Employeeclasse Je demande le principe de moindre connaissance en soi, et en le faisant , nous automatiquement limiterai couplage à seulement cette classe, et en même temps isoler le couplage à celui d' une classe.

En ajoutant toutes les propriétés nécessaires dans le Employee classe, nous fixons le couplage.

Donc

public class Employee {
    public Person me = new Person();
    public string street { return me.home.street; }
}

Me permet d'appeler: myEmployee.street-

1. Je "connais" seulement Employee
2. Je suis couplé à seulement Employee- peu importe la complexité de sa structure.

La moindre connaissance jusqu'en bas

Nous découplé myEmployee de Personet Address, et , idéalement , nous devrions continuer à appliquer les connaissances moins en ajoutant passe par des propriétés telles que Employeeparle seulement Personet Personparle seulementAddress

Une étude ( V. Basili, L. Briand et WL Melo. Une validation des métriques de conception orientée objet en tant qu'indicateurs de qualité ) a montré que les classes avec des ensembles de réponses plus importants ont tendance à créer plus d'erreurs que les classes avec un ensemble de réponses plus petit car plus d'ensemble de réponses signifie la possibilité d'un couplage plus élevé.

La valeur de la loi de Demeter est qu'elle réduit la réponse définie par définition. La méthode d'un objet ne peut appeler qu'une méthode de lui-même, tout paramètre transmis à la méthode, la méthode de tout objet qu'il a créé et la méthode de tout objet détenu directement. Étant donné que l'ensemble de réponses est plus petit, il y a moins de chances de couplage élevé. Étant donné que le module / méthode n'utilise que des références disponibles immédiatement, la cohésion est plus élevée.

C'est assez simple; disons que A dépend de B et B dépend de C. Sans la loi de Déméter, vous pouvez utiliser à la fois B et C dans A mais en adhérant à cette loi, A ne dépend que de B, cela ne peut pas dépendre de C.

Cela permet un faible couplage car il réduit considérablement le nombre de dépendances d'un module; la cohésion, bien que différente dans son concept du couplage, est réalisée de la même manière. En ayant moins de dépendances sur un module, celles-ci deviennent plus spécifiques pour ce module et augmentent ainsi la cohésion. De plus, le nombre total de modules augmentera et ils deviendront plus spécialisés pour faire des choses spécialisées pour le module dépendant (contrairement aux objets divins) qui se traduisent directement en un système plus cohérent.