ソフトウェア開発メモ

日々のソフトウェア設計、実装で考えている、気づいた事を書いています。それが真実か否かは保証しません。悪しからず。

ドメインモデル貧血症についてのその後

iOSアプリでのドメイン貧血症について - 概念構築メモ

のついて悩みに悩んで、とある開発会社のコラムに似たような事が書いてあった。端的にいうとこれ。

モデル⇔ビュー、モデル⇔ネットワーク、モデル⇔RDB等、 データ変換が必要な所は関数やユーティリティクラスで設計せざる得ない。

まあ、そうやろうね。。クラスAからクラスBへの変換を行なう際、A側にメソッドを実装するか、B側にメソッドを実装するか、はたまた関数あるいはユーティリティを実装するかの3つの選択肢から判断する必要がある。後は、GRASPでいう人工品をでっち上げるとか。

とういう事でエンティティ系クラスに関していうと属性の完全隠ぺいは不可能。業務系の事は分からないけど、DOAを今でも使っていたりするのはこのような理由かな? データ変換主体のシステムのクラス構成ってどうなっているんだろう?