DTO は広く使用されており、実際の問題を「解決」していますね。

問題

• 貧血オブジェクト
• 一貫性のないデータ
• 重複したロジック
• 重複構造
• クラス汚染
• 情報隠蔽違反
• ミューテーター、アクセサー、シリアライザー、パーサーの間で繰り返されるコード
• 波及効果
• データの整合性

1. アレイ上の貧血データを転送します。
2. 実際のビジネス オブジェクトを使用します。
3. 部分的なオブジェクトを転送したい場合: プロキシまたは null オブジェクトを使用して参照グラフを壊します。

違う

右

検出

同じ貧血オブジェクト検出器を使用できます。

ビジネス オブジェクトの動作がない貧血クラスをチェックできます (シリアル化、コンストラクター、ミューテーターなどの削除)。

タグ

• 貧血

DTO はツールであり、一部の言語では確立されたプラクティスです。注意と責任を持って使用する必要があります。

オブジェクトを領域から遠ざけるためにオブジェクトを分解する必要がある場合は、非常に注意する必要があります。解体されたオブジェクトには整合性に関する考慮事項がないためです。

彼の著者は、実際の乱用について警告しています。

関係

Code Smell 01 — 貧血モデル Code Smell 13 — 空のコンストラクタ Code Smell 20 — 時期尚早の最適化 Code Smell 28 — セッター

より詳しい情報

最高の匂いとは、簡単に見つけられるものであり、ほとんどの場合、非常に興味深い問題につながります。データ クラス (すべてのデータを持ち、動作を持たないクラス) は、この良い例です。あなたはそれらを見て、このクラスでどのような振る舞いをすべきかを自問します。

マーティン・ファウラー

ソフトウェアエンジニアリングの名言

この記事は CodeSmell シリーズの一部です。

コードの臭い部分を見つける方法