Discussion :

[Mickael Baron]

Colin Damon, d'Ippon Technologies, vous propose un tutoriel Java qui pr�sente les bonnes pratiques pour d�velopper des Objets Java et pas seulement des classes de donn�es

Le lien de l'article : https://ippon.developpez.com/tutorie...lassesdonnees/

Profitez de cette discussion pour faire part de vos remarques, commentaires ou d'�ventuelles informations ou techniques compl�mentaires.

L'�quipe Java

Retrouvez les meilleurs cours et tutoriels pour apprendre Java

[gervais.b]

Dommage que le lien avec le Domain Driven ne soit pas fait. Sans entrer dans les d�tails, l'auteur aurait pu faire le rapprochement et m�me emprunter des termes.

[Cincinnatus]

Bonjour,

La plus grande partie de l'article discute de la coh�rence des objets. La premi�re section me fait penser aux types de donn�es qu'il est possible de cr�er en Ada (exemple : num�rique entier de 1 � 100, pas un entier qu'il faudra ensuite contr�ler). Ensuite, v�rifier les donn�es en entr�e �voque pour moi le langage Eiffel et la conception par contrat (notamment les pr�conditions). Enfin les types immuables sont de plus en plus utilis�s dans d'autres langages comme Scala ou Kotlin.

Le reste de l'article est plus orient� API (rest en particulier).

Le sujet de l'article est plus "types de donn�es" que conception d'objets m�tier, ce qui serait plus utile � beaucoup. Comme dit par @gervais.b, le DDD serait une tr�s bonne approche dans ce cas. Je trouve n�anmoins l'article int�ressant pour ce rappel du besoin de contr�les des donn�es au niveau des objets eux-m�mes pour garantir leur coh�rence avec leurs valeurs m�tier.

https://www.eiffel.org/doc/solutions...and_Assertions

[PhilippeGibault]

Juste pour rappeler que pour v�rifier la coh�rence d'un objet/classe repr�sentant un concept, il existe un excellent framework, tr�s simple, qui s'appelle Hibernate validator.
C'est m�me devenu une norme (JSR 303).

[marc.collin]

Juste pour rappeler que pour v�rifier la coh�rence d'un objet/classe repr�sentant un concept, il existe un excellent framework, tr�s simple, qui s'appelle Hibernate validator.
C'est m�me devenu une norme (JSR 303).

en cherchant un peu sur la toile, tu pourras remarquer que certain conteste cette approche.

En fait, au niveau du ddd je n'ai jamais vu autant de contestation et d'incertitude et de l'avis m�me d'Evans l'approche s'applique � peu de projet, m�me si elle est tr�s int�ressante.

[professeur shadoko]

bien mais avec un petit b�mol toutefois.
Il faut une grande �ducation des programmeurs pour leur faire toucher du doigt la pertinence des contr�les de validit�.
A l'�poque du COBOL on enseignait aux programmeurs de tout v�rifier ... avec parfois des exc�s surprenants
(cas extr�me : au Pays_bas un gars v�rifiait que les noms de famille respectaient bien les r�gles de l'alphabet n�erlandais... sauf que beaucoup de noms l� bas sont soit d'origine fran�aise ou allemande! Bonjour les d�gats). J'avais aussi un copain malgache dont le nom comportait plus d'une trentaine de lettres et ne rentrait pas dans les formulaires!

On trouve encore ce genre d'exc�s actuellement: les sites am�ricains qui vous demandent un �tat � l'int�rieur de votre pays, les listes de nationalit�s (ben oui: quid si tu es "apatride n� dans la bande de Gaza sous administration �gyptienne"?) mais le plus dr�le m'est arriv� personnellement: un programmeur v�rifiait les dates de naissance et ne pouvait admettre que j'�tais n� avant 1950! j'ai eu r�cemment un autre exemple saignant avec l'application TousAntiCovid qui m'a emp�ch� de me d�clarer comme positif!.
Donc oui aux v�rifications syst�matiques ... mais le mieux est l'ennemi du bien! penser � des proc�dures de secours si �a vous semble hors limite.

[cdamon]

Bonsoir,

merci pour les retours (que j'ai encore oubli� de surveiller ).

Pour le lien non fait avec DDD c'est volontaire (et j'ai m�me du me retenir � de nombreuses reprises). Je pense qu'ajouter du vocabulaire parfois complexe du DDD peut faire peur et n'aurais pas forcement apport� au propos ici.
Pour l'utilisation de BeanValidation (JSR 303 et 380 je crois) je ne suis absolument pas pour dans le domain (code du m�tier, celui qui est vraiment important) ou je pr�f�re largement faire des contr�les proche du m�tier qui me "forceront" aussi l'utilisation de patterns de construction adapt�s (je verrais donc �merger des designs plus �l�gants). J'utilise habituellement des architectures hexagonales et je vais plut�t utiliser ce type de validation dans les primary adapters.

[ben53]

Bonjour,
Il y a quelque chose que je ne comprends sinc�rement pas. Quelqu'un pourrait-il me donner un exemple d'objet "m�tier"?

[cdamon]

Bonjour,

@ben53 quand on fais une application on doit rendre un service donn�, on doit donc faire du code pour faire diff�rentes op�rations. Il existe plusieurs mani�re de le faire : on peux choisir de ne repr�senter que les donn�es (on parle alors de data classes) et faire les traitements dans des services stateless ou, on peux faire des objets repr�sentant le m�tier qui seront charg�s de faire les op�rations.

Par exemple, si on doit manipuler un num�ro de t�l�phone on peux choisir de transporter uniquement une cha�ne de caract�res, nos services doivent donc pouvoir traiter un num�ro de t�l�phone ou un dictionnaire Klingon. Ou alors on peux avoir un objet repr�sentant ce num�ro de t�l�phone qui fera le contr�le et le formatage de la donn�e. En plus de nous donner une indication fiable et importante sur le type de donn�e (c'est un num�ro de t�l�phone, pas un pr�nom) on est aussi certains de manipuler des donn�es saines. Maintenant, sur ce num�ro de t�l�phone on peux avoir besoin d'ajouter l'indicateur du pays (une op�ration m�tier n�cessaire dans l'application) et bien la logique pour faire cette op�ration peut �tre cod�e directement dans notre objet t�l�phone.

Dans le cas du num�ro de t�l�phone, dans cet exemple, seules les valeurs port�es sont importantes, si on change ces donn�es on manipule alors un autre num�ro de t�l�phone : en DDD on appel ce type d'objets des value objects. Dans la boite � outils du DDD on va trouver d'autres mani�res de mod�liser le m�tier (Aggregates, Entities, Domain Events, ...) mais �a, c'est une autre (tr�s longue) histoire . Si ces sujets t'int�r�sent je te conseil de te renseigner un peu (par exemple en lisant Domain Driven Design Distilled de Vaughn Vernon) puis d'aller participer � des groupes de discussion sur le sujet pour en apprendre un peu plus.