Version imprimable
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
:fleche: Retrouvez les meilleurs cours et tutoriels pour apprendre Java
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.
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
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.Citation:
Envoyé par PhilippeGibault
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.
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.
Bonsoir,
merci pour les retours (que j'ai encore oublié de surveiller :D).
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.
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"?
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.