Pioneer Plot: StepOwner
Yes, I have made a sudden reappearance, much to the chagrin of my foes, both domestically and internationally. We are not at Full Throttle, not at all, and the armory will be at half capacity for the foreseeable future.
However, we will continue with short posts on design problems I have faced recently as I take the reigns of a tech lead on a new agile team. It is a feature I just invented, and I think I’ll call it Pioneer Plot.
I left you with a simple problem: an entity, Step, has a StepOwner, which could be one of two implementations – a Client or the System itself. The behavior of the system is dependent on the instanceof StepOwner.
My answer
It is amazing how ingrained a procedural mind-set can be, even after all of the object-oriented epiphanies this blog has afforded me.
- I considered instanceof.
- I considered a isSystem() method on StepOwner.
- I considered a isSystemStep() method on Step.
- I considered some sort of HashMap design to avoid the tangle of if-statements that would surely result.
- I considered making StepOwner a class and assuming that if the client ID is null that you have a system-owned step.
- I considered making StepOwner follow a Null Object Pattern and creating an implementation to represent a system-owned step.
- I considered a hybrid of some of the options above.
- I considered a couple of other options that I don’t recall right now.
It’s simple, actually: I think instead of generalizing on StepOwner, I should be generalizing on Step. the behavior of Step depends on whether it is a SystemStep or a ClientStep. Step can have a handle() method and the specific behavior can go in there.
But Moff, but Moff, now the business object is doing work that doesn’t fit its responsibility.
Dude, relax. I’m gonna nail it.
Each of these implementations can double-dispatch their way to a StepHandler; say handleWith(StepHandler).
But Moff, but Moff, each type of Step has different data attributes. What about the StepRepository?
Double-dispatch, baby.
Next plot
Congratulations! You are developing a domain model layer. Assuming your UI will send you dumb data transfer objects, how will your application layer consume it such that the business logic in your entities, value objects, aggregates, and so forth is not completely by-passed by blind mapping from DTOs to domain objects?
Mr. Blogcast Engineer, theme music out.
COME my tan-faced children,
Follow well in order, get your weapons ready,
Have you your pistols? have you your sharp-edged axes?
Pioneers! O pioneers!
For we cannot tarry here,
We must march my darlings, we must bear the brunt of danger,
We the youthful sinewy races, all the rest on us depend,
Pioneers! O pioneers!
 |
Announcer: You’re reading the EIP web-ring. |
