私は食事計画アプリケーションに取り組んでいます。さまざまな日に食べたいもののリストである MealSchedule があります。その MealSchedule は、最終的には、その日に食べたいものを作成する製品とレシピの食料品リストである MealPlan に変わります。
MealPlan は MealSchedule から作成されるため、MealSchedule を取り込む MealPlan のコンストラクターを作成したいと思います。残念ながら、このプロセスはかなり複雑であり、過度に複雑なコンストラクターを作成するというアンチパターンにつながると思います。
逆に言えば、ビルダーを使用して MealPlan を作成すると、MealPlan は貧弱なオブジェクトになり、MealPlan に密接に関連するこのロジックは含まれません。2 つの悪のうち、最も小さいのはどれですか。
MealPlan変更可能で、状態を追跡する必要がある本格的なエンティティですか、それとも値オブジェクトにすることができますか？可能であれば、貧血であることを心配する必要はなく、その構造をある種のに委任することができますMealPlanBuilder。
いずれにせよ、私がすることは、ユビキタス言語を洗練し、ドメインの専門家と話し合って、食事プランジェネレーターのようなものがビジネス用語で意味があるかどうかを確認することです。答えが「はい」の場合、あなたはあなたのオブジェクトを持っています。食事プランの作成プロセスについて、次のように非常に正確で明確に表現された言葉で関係者と話すことができるので、それも非常に実用的だと思います。
「ユーザーが毎週の食事プランと毎日の食事プランのどちらかを選択できるように、食事プランジェネレーターを変更する必要があります...」
食事プランを生成するという概念自体がそれほど重要ではない場合は、そのロジックをMealPlanコンストラクターに残すことを検討してください。
補足として、貧弱性は、各ドメインオブジェクトで体系的に追跡および根絶する必要があるアンチパターンではないことを付け加えておきます。確かに、オブジェクトに動作がある場合は、できる限り動作するようにする必要がありますが、一部のオブジェクトではそれが不可能な場合があります。完全に貧血のドメイン層が悪いからといって、たまに貧血の対象になるためにむち打ちをする必要があるという意味ではありません。
これは、いくつかの（すべてではなく、いくつかの）同様のケースで私のために働いたアプローチの大まかな「スケッチ」です。過去にこれらのオプションに直面したとき、私はその小さなKISSが大好きなので、一歩後退しました-Keep it Simpleソフトウェアエンジニア。
基本的な (貧血?) 基本クラスから始めます。これらの複雑なオプションを (ポリモーフ) 子クラスとしてモデリングし始めます。共通性の層があることを喜んでください。それは長期的に見返りがあります (より洗練されたアプリケーションでは、おそらく食事スケジューラではありません)。例; データ フィールドがある場合は、「フィールド」クラスを使用できます: 「数値」/「テキスト」/「ブール値」/「URI」。戻る: URI: URL、電子メール、Wget; テキスト: TextField、TextArea、Literal、...
アプリケーションにとって意味のあるものでなければなりません。あなたは見ることができます：
アイデアは、静的な選択が定義で「開発」される可能性があるため、コンパイラとクラスの関係ロジックにコードを本当に馬鹿にするように要求することです。木曜日の昼食だとわかったら ... EAT = new lunch( 木曜日 ) ... コンストラクタを賢くすると、ずっと下にカスケードします。
この種のことをしようとする私の最初の「試み」は完全な混乱でした! そして、私はそれをあきらめました。次回はもっと考えますが、始めるのに十分な何かができるまで、いくつかのクラスを試してください（鉛筆と紙が役立ちます）. それからクラスファミリーを試してみてください - そして情熱を持って REFACTOR を試してみてください。
幸運を ：-）