Anemic object or overworked constructor?

Question

I'm working on a meal planning application. I have a MealSchedule which is a list of things that I want to eat on various days. That MealSchedule will eventually get turned into a MealPlan which is a grocery list of products and recipes that will be create the things I want to eat on each of those days.

Since the MealPlan is created from a MealSchedule I would like to create a constructor for a MealPlan which takes in a MealSchedule. Unfortunately, this process is fairly complicated and I feel that would lead to the anti-pattern of creating an overly complicated constructor.

On the flip side, if I use a builder to create the MealPlan then the MealPlan becomes a rather anemic object and doesn't contain this logic that relates so closely to the MealPlan. Which is the least of two evils, or more likely, what am I missing?

Answer 1

Is MealPlan a full fledged entity that can be modified and whose state must be tracked, or could it be made a Value Object ? If it could, then you don't need to worry about it being anemic and you might delegate its construction to some kind of MealPlanBuilder.

In any case, what I would do is try to refine the ubiquitous language and talk with a domain expert to see if such a thing as a Meal Plan Generator would make sense in business terms. If the answer is yes, then you have your object. I think it would also be very practical as you'd be able to talk about the Meal Plan generation process with the stakeholders in very precise, clearly expressed terms, as in

"We need to change the Meal Plan generator to allow the user to choose between a weekly and a daily meal plan..."

If the concept of generating Meal Plans is not such an important thing in itself, then you may consider leaving its logic in the MealPlan constructor.

As a side note, I'd add that anemicness is not an anti-pattern you should systematically track and eradicate in each of your domain objects. Sure, it's better when your objects do have behavior and you should look to do it every time you can, but for some objects it's just not possible. Just because an entirely anemic domain layer is bad doesn't mean that you need to flog yourself for your occasional anemic object.

Answer 2

This is just a rough 'sketch' of an approach that worked for me in some (not every, just some) similar cases. In the past when faced with those options, I take a step back because I love that little KISS -- Keep it Simple Software-engineer.

Begin with a basic (anaemic?) base class. Start modelling those complex options as (polymorph) child classes. Be happy to have layers of commonality, it will pay off long-term (in more sophisticated applications, perhaps not a meal scheduler). An example; if you have a data field you can have a 'Field' class: 'Numerics' / 'Text' / 'Boolean' / 'URI'. Step back: URI: URL, Email, Wget; Text: TextField, TextArea, Literal, ...

It has to make sense to your application. You could look at:

• Meal: Sitting / Snack
• Sitting: Lunch / Breakfast / Dinner
• Snack: Morning Tea / Afternoon Tea / Supper / Raid the Fridge

The idea is to ask the compiler and class relationship logic to force your code to be really dumb because the static choices can be 'developed' in the definition. Once you know it is lunch on Thursday ... EAT = new Lunch( Thursday ) ... if you make your constructors smart; will cascade all the way down.

My first 'attempt' to do this kind of thing was a complete mess! And I gave it up. The next time I just though think more, try some classes (a pencil and paper helps) until you have something good enough to begin. Then trial the class family - Then REFACTOR with passion.

Good luck :-)