Question

L'article sur wikipedia à propos de Loi de Demeter dit:

  

La loi peut être énoncée simplement comme "n'utilisez qu'un seul point".

Cependant, un Exemple simple d'une interface courante peut ressembler à ceci:

static void Main(string[] args)
{
   new ZRLabs.Yael.Pipeline("cat.jpg")
        .Rotate(90)
        .Watermark("Monkey")
        .RoundCorners(100, Color.Bisque)
        .Save("test.png");
}

Alors, est-ce que cela va ensemble?

Était-ce utile?

La solution

Eh bien, la définition courte de la loi la raccourcit trop. Le vrai " loi " (en réalité, des conseils sur la bonne conception d’API) indiquent essentiellement: Seuls les objets d’accès que vous avez créés vous-même ou qui vous ont été transmis en tant qu’argument. Ne pas accéder aux objets indirectement à travers d'autres objets. Les méthodes d'interfaces fluides renvoient souvent l'objet lui-même, elles ne violent donc pas la loi si vous utilisez l'objet à nouveau. D'autres méthodes créent des objets pour vous, donc il n'y a pas non plus violation.

Notez également que la " loi " n’est qu’un conseil en matière de pratiques exemplaires pour «classique». Apis. Les interfaces fluides représentent une approche complètement différente de la conception des API et ne peuvent pas être évaluées avec la loi de Demeter.

Autres conseils

Pas nécessairement. " N'utilisez qu'un seul point " est un résumé inexact de la loi de Demeter.

La loi de Demeter déconseille l’utilisation de plusieurs points lorsque chaque point représente le résultat d’un objet différent, par exemple:

  • Le premier point est une méthode appelée depuis ObjectA, renvoyant un objet de type ObjectB
  • Le point suivant est une méthode uniquement disponible dans ObjectB, renvoyant un objet de type ObjectC
  • Le point suivant est une propriété disponible uniquement dans ObjectC
  • ad infinitum

Cependant, à mon avis au moins, la loi de Demeter n'est pas enfreinte si l'objet de retour de chaque point est toujours du même type que l'appelant d'origine:

var List<SomeObj> list = new List<SomeObj>();
//initialize data here
return list.FindAll( i => i == someValue ).Sort( i1, i2 => i2 > i1).ToArray();

Dans l'exemple ci-dessus, FindAll () et Sort () renvoient le même type d'objet que la liste d'origine. La loi de Demeter n’est pas violée: la liste n’a parlé qu’à ses amis immédiats.

Cela étant dit, toutes les interfaces fluides ne violent pas la loi de Demeter, tant qu'elles renvoient le même type que leur correspondant.

Oui, même si vous devez appliquer un peu de pragmatisme à la situation. Je prends toujours la loi de Demeter comme une ligne directrice par opposition à une règle.

Évidemment, vous voudrez peut-être éviter ce qui suit:

CurrentCustomer.Orders[0].Manufacturer.Address.Email(text);

peut-être remplacer par:

CurrentCustomer.Orders[0].EmailManufacturer(text);

Au fur et à mesure que nous utilisons ORM, qui présente généralement le domaine entier sous forme de graphe d'objet, il peut être judicieux de définir un "scope" et un champ acceptables. pour un objet particulier. Peut-être devrions-nous prendre la loi de Demeter pour suggérer que vous ne devriez pas tracer le graphique entier comme accessible.

L’esprit de la loi de Demeter est que, étant donné une référence ou une classe d’objet, vous devez éviter d’accéder aux propriétés d’une classe située à plus d’une sous-propriété ou méthode, car elles coupleraient étroitement les deux classes, ce qui pourrait être involontaire. et peut causer des problèmes de maintenabilité.

Les

interfaces fluides constituent une exception acceptable à la loi, car elles signifient d'être au moins assez étroitement associées, car toutes les propriétés et méthodes sont les termes d'un mini-langage qui sont composés ensemble. former des phrases fonctionnelles.

1) Cela ne la viole pas du tout.

Le code est équivalent à

var a = new ZRLabs.Yael.Pipeline("cat.jpg");
a = a.Rotate(90);
a = a.Watermark("Monkey");
a = a.RoundCorners(100, Color.Bisque);
a = a.Save("test.png");

2) Comme bon Ol 'Phil Haack dit: La loi de Demeter n’est pas un exercice de comptage de points

Votre exemple ne pose pas de problème. Après tout, vous faites une rotation, un filigrane, etc ... toujours la même image. Je crois que vous parlez tout le temps à un objet Pipeline. Par conséquent, tant que votre code ne dépend que de la classe du Pipeline, vous ne violez pas le LoD.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top