Les DTO sont largement utilisés et « résolvent » de vrais problèmes, n'est-ce pas ?

Problèmes

• Objet anémique
• Données incohérentes
• Logique dupliquée
• Structure dupliquée
• Classe polluante
• Violation de la dissimulation d'informations
• Code répété parmi les mutateurs , les accesseurs, les sérialiseurs , les analyseurs
• Effet d'entraînement
• Intégrité des données

1. Transférer des données anémiques sur des tableaux.
2. Utilisez de vrais objets métier.
3. Si nous voulons transférer des objets partiels : utilisez des proxies ou des objets nuls pour casser le graphe de référence.

Mauvais

Droit

Détection

Nous pouvons utiliser les mêmes détecteurs d'objets anémiques.

Nous pouvons rechercher des classes anémiques sans comportement d'objet métier (suppression des sérialisations, des constructeurs, des mutateurs, etc.).

Mots clés

• Anémique

Les DTO sont un outil et une pratique établie dans certaines langues. Nous devons les utiliser avec soin et responsabilité.

Si nous devons démonter nos objets afin de les envoyer loin de nos royaumes, nous devons être extrêmement prudents. Étant donné que les objets démembrés n'ont aucune considération d'intégrité.

Son auteur nous met en garde contre son abus réel.

Rapports

Code Smell 01 — Modèles anémiques Code Smell 13 — Constructeurs vides Code Smell 20 — Optimisation prématurée Code Smell 28 — Setters

Plus d'informations

Les meilleures odeurs sont quelque chose de facile à repérer et la plupart du temps vous amènent à des problèmes vraiment intéressants. Les classes de données (classes avec toutes les données et aucun comportement) en sont de bons exemples. Vous les regardez et vous vous demandez quel comportement devrait être dans cette classe.

Martin Fowler

Excellentes citations de génie logiciel

Cet article fait partie de la série CodeSmell.

Comment trouver les parties puantes de votre code