On 05/02/2011 09:11 AM, info@tomsik.cz wrote:
I see that #become: is hard to follow in code (either for human or analysis tools)
I'm trying to express state-pattern:
OpenedDoor>>close ClosedDoor>>open
And I would like to avoid this: Door>>close state close. Door>>open state open.
Because if Door cannot be opened depending on its current state, IMHO no method should be there. Which is why become: seems as the best fit.
You can simply have the #open method do nothing in certain states, or throw an exception. No need for messageNotUnderstood. You absoluletly do not want to use become: for such an example. All in all, I'm not sure how I feel about creating a new first class object to represent each of a door's states. The last time I recall using #become: was for low level and carefully protected behavior needed by an ORB. become should come with a special form which needs to go through three levels of sign off before you should be allowed to use it in your code. ~Jon