La loi de Demeter

Bonjour,
PMD m'indique que mon code est en Violation potentielle de la loi de Déméter (objet non créé localement).
Dans ce simple petit bout de code :

Code:

---

1 2 3 4 5 6 7

final SimpleDateFormat FORMAT_DATE = new SimpleDateFormat("yyyy-MM-dd.HH.mm.ss", Locale.FRENCH); final SimpleDateFormat FORMAT_TIMESTAMP = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSSSS", Locale.FRENCH); final Date dateCharge = new Date(System.currentTimeMillis()); final Timestamp timeCharge = new Timestamp(dateCharge.getTime()); final String dateStringCharge = FORMAT_DATE.format(dateCharge); final String timeStringCharge = FORMAT_TIMESTAMP.format(dateCharge);

---

Les 3 dernières lignes sont en violation potentielle.
J'en conclu que mon code devrait être améliorer afin d'éviter cette violation (dont j'ai du mal à saisir les tenants et aboutissants).
Je vous remercie d'avance pour les éclaircissement que vous pourrez m'apporter.

Je pense que cela viens du fait que tu essais d'initialiser des constantes avec d'autre constantes. Pour le vérifier enlève les mots clé final devant et regarde à la compilation ce qu'il te dit.

Citation:

---

Envoyé par wikipedia

La Loi de Déméter pour les fonctions requiert que toute méthode M d'un objet O peut simplement invoquer les méthodes des types suivants d'objets :

lui-même
ses paramètres
les objets qu'il crée/instancie
ses objets composants

---

Le but c'est d'éviter les codes spaghettis et la collaboration trop ténues entre les objets.


Je pense que la solution serait:

Code:

---

1 2 3 4 5 6 7 8

final SimpleDateFormat FORMAT_DATE = new SimpleDateFormat("yyyy-MM-dd.HH.mm.ss", Locale.FRENCH); final SimpleDateFormat FORMAT_TIMESTAMP = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSSSS", Locale.FRENCH); final Date dateCharge = new Date(System.currentTimeMillis()); final Timestamp timeCharge = buildTimestamp(dateCharge);   public static Timestamp buildTimestamp(Date date){ return new Timestamp(date.getTime()); }

---

Merci tchize. Code testé et approuvé :ccool:
Reste plus qu'à creuser cette loi car elle provoque énormément d'alertes dans mon code !

Citation:

---

Envoyé par shibo

Merci tchize. Code testé et approuvé :ccool:
Reste plus qu'à creuser cette loi car elle provoque énormément d'alertes dans mon code !

---

Je ne la connaissais pas avant, mais d'après l'article de wikipedia, un des reproches qu'on lui fait, c'est de te forcer à multiplier les petites méthodes comme je viens de proposer....

L'idée de la loi de Demeter est de ne parler qu'à ses amis les plus proches dans le but de limiter le couplage. C'est à dire que ce genre de choses est à proscrire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public class MaClass { Employes employes;   public void doSomething(Employe employe){ // code métier de la classe   employes.getListeEmployes.add(employe);   // suite du code métier de la classe } }

---

D'après la loi de Demeter il faudrait plutôt que la classe Employes dispose d'une méthode pour ajouter un employé afin que "MaClass" ne dépende pas du contenu de Employes. "MaClass" ne doit pas savoir comment sont stockés les employés (que ça soit dans une liste, dans une Map, dans un Set, ... ), "MaClass" veut juste ajouter un employé :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public class MaClass { Employes employes;   public void doSomething(Employe employe){ // code métier de la classe   employes.ajouterEmploye(employe);   // suite du code métier de la classe } }

---

Ainsi "MaClass" n'est pas couplée avec le système de stockage des employés dans la classe Employes. La classe "Employes" peut changer à tout moment son système de stockage sans que "MaClass" soit impacté. La loi de Demeter va avec le principe du "Tell Don't Ask". Exemple : Si on veut mettre un String en minuscule, on ne demande pas au String son tableau de char[] pour ensuite mettre chacun des char en minuscule, on demande directement au String de créer un nouveau String en minuscule : monString.toLowerCase();

NB : Le pattern factory conduit souvent à la violation de a loi de Demeter. puisqu'on effectue en général "factory.buildC().doSomething()".

Romain.

En l'occurrence Date et Timestamp sont tous deux des types de données basiques de Java, utilisés fréquemment par l'algorithme, donc considérables comme "amis proches."

Pareil, la factory et les objets qu'elle construit sont deux amis proches différents. Le rôle de la factory est de créer des objets, et rien d'autre. C'est à ces objets qu'on applique ensuite le "tell don't ask."

PMD fait ce qu'il peut, mais la loi de Déméter n'est pas vérifiable par une machine, tout dépend de ce qui est un "ami proche." C'est pour ça qu'il parle de violation "potentielle."

Les mais proches ne sont pas définis par le type des objets. Source wikpédia :

Citation:

---

More formally, the Law of Demeter for functions requires that a method m of an object O may only invoke the methods of the following kinds of objects:[2]

O itself
m's parameters
Any objects created/instantiated within m
O's direct component objects
A global variable, accessible by O, in the scope of m

---

Dans son cas je n'ai pas l'impression qu'il viole la loi de Demeter, il n'appelle que des méthodes sur des objets qu'il a créés localement (mais pour en être sur il faudrait voir la méthode ou la classe en entière...).

Hors sujet : L'écriture des variables FORMAT_TIMESTAMP et FORMAT_DATE ne respecte pas les normes Java. Ce format est réservé aux variables static. Pour une variable final il faut simplement écrire "formatDate" et "formatTimestamp". La mauvaise écriture induit en erreur, j'ai pensé que les variables étaient static au premier coup d’œil, ce qui aurait été un bug potentiel car SimpleDateFormat n'est pas thread safe.

Romain.

Merci pour le complément d'info sur cette loi (et sur le hors sujet).