Le problème de ce principe, c'est qu'il oppose service et données : il faut effectivement penser "service", mais parfois ton service c'est d'exposer des données : DTO, Controller, DOM, Composants IHM, etc.
C'est pour ça que je parlais plutôt de la partie fonctionnelle du code, les classes dont l'objectif est de fournir des données ne rentrent pas dans ce cadre.
Si tu veux changer tes roues, tu as :
* une factory qui sait te fabriquer des roues
* une méthode changeWheels() de la voiture pour changer les roues
Ce que la loi t'incite à faire, c'est à raisonner en terme fonctionnel et à faire l'analyse des services fournis par ton objet. Et encore un fois, je ne parle pas ici des classes vraiment techniques (factory, parser, container, ...).
Pour reprendre l'exemple de The Paperboy, The Wallet, and The Law Of Demeter, Lorsque le garçon doit payer, on peut avoir :
* une classe Customer avec une méthode getWallet et la caissière prend le porte monnaie et enlève l'argent du porte monnaie
* ou alors une class Customer avec une méthode pour payer
Comme le dit la section "Why Is This Better?", la deuxième solution représente mieux le monde réel.
[^] # Re: Chacun son style
Posté par Étienne . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
C'est pour ça que je parlais plutôt de la partie fonctionnelle du code, les classes dont l'objectif est de fournir des données ne rentrent pas dans ce cadre.
Si tu veux changer tes roues, tu as :
* une factory qui sait te fabriquer des roues
* une méthode changeWheels() de la voiture pour changer les roues
Ce que la loi t'incite à faire, c'est à raisonner en terme fonctionnel et à faire l'analyse des services fournis par ton objet. Et encore un fois, je ne parle pas ici des classes vraiment techniques (factory, parser, container, ...).
Pour reprendre l'exemple de The Paperboy, The Wallet, and The Law Of Demeter, Lorsque le garçon doit payer, on peut avoir :
* une classe Customer avec une méthode getWallet et la caissière prend le porte monnaie et enlève l'argent du porte monnaie
* ou alors une class Customer avec une méthode pour payer
Comme le dit la section "Why Is This Better?", la deuxième solution représente mieux le monde réel.
Étienne