in reply to Re^14: Assignable Subroutines
in thread Assignable Subroutines

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.

Replies are listed 'Best First'.
Re^16: Assignable Subroutines
by fergal (Chaplain) on Jan 27, 2005 at 21:17 UTC
    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]
        But as I already said in the thread with dragonchild, he's missed a few reasons for changing the salary and he's missed a couple of methods of calculating the new salary. So basically what you'll end up with is a combinatorial explosion of salary adjusting methods. n methods where n = (# reasons) * (# ways of calculating new salary).

        So lets refactor slightly and have a business level interface (where changes to salary require a reason). You may have several specific methods and probably one that says "just set it to this much and here's a piece of text for the audit log about why I did it". All of these will need to call the actuall Salary method on a lower level object and also put something in the log. It should not be the responsibilty of the Employee object to handle logging.

        Moving away from Salary and business rules, it's quite possible that you just want to change a field's value without supplying any other information. As someone else pointed out, the object may then need to signal observers to update the gui or whatever but the thing requesting the change just wants to treat it like a struct.

[reply]

In Section Meditations