You end up having insufficient checks in the object. Actually, I think dragonchild's giveRaise() and givePromotion() methods are better than my solution (these two methods could potentially be implemented with Effects, though I'm not sure why you would want to). In both cases, it's clear from the method name alone what is going to be done.
Further, there are two different reasons given here for changing the salary of an existing employee, and they both likely have completely different buisness rules behind them. With dragonchild's method, those buisness rules will be completely seperated by two different methods.
The Effect^H^H^H Visitor Pattern is still applicable in some applications, such as implementing the massive flexibility required by my game framework.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply]
[d/l]
[select] |
You end up having insufficient checks in the object.
Why do I end up with that? What is stopping me from adding in the extra checks that would make it sufficient? I'm talking about an object that has struct like fields that are only accessible through mutators so I can check anything I like at set time.
| [reply] |
Why are you modifying the salary? General raise or promotion? How do you tell your mutator which reason and apply the business rules as needed?
With completely seperate methods for each, the reason will be blindingly obvious. You don't even need a conditional to figure it out in the object's code.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |