|
OO Instead of Flags Why flags should be avoided and objects designed Programming and Design, 090803 Object oriented design and methodology, indeed a most interesting topic. I used to be teaching this stuff back when was working at the university in Umeå. I still thing about this stuff a lot since I work daily with Java and find design patterns and all that jazz really interesting. This is a little that I have learned about flags. Some programmers seems to love flags. I do not. This is why: In my opinion flags are locking the programmer into a situation where the code have to evolve and grow around the flags. If new problems and contexts has to be dealt with, new flags has to be inserted in order to handle this new state. But there is a better way to do this... The flag indicating a state is like the finger pointing at the moon; the flag is telling about a state but is not in itself the actual state. The actual state of the object, are all the actual values of the attributes in the object. These values seen as a whole, is the state of the object. Now, if you want to change the state instead of changing the flag you change the attributes. And since the state of the object is dependent on the context in which the object is used, the state of the object is set from outside the object by the objects using the stateful object. So what you do when you design your object is to make a bunch of setters and getters for the object attributes. Then you invoke these methods from the context in which the object is existing and voila you are home free. Instead of methods like this: overrideWithNewConnection(int newPort) you get something like this: close(), open(int newPort). Easier to read API and everything. Do you understand the difference? Instead of having methods in the object that tries to do "smart things in relation to the context" with the objects state, you do the smart things out in the context and think about the object as nothing more then a data holders. This will also actually be much easier since the context knows stuff about itself that the object will never know. All objects should be stupid in themselves. What should be smart is the way in which different stupid objects are combined. Just like your brain. The separate braincell is not smart, but those little cells working together... amazing! Flags are all about trying to make the objects smart and intelligent and somehow know how to handle stuff and the only way the can ever even come close to this, if you fill the object with tons and tons of code that handles all the different situations. And yes of course, the objects that are the context of the stateful object, should also be designed in the same way. Thus everything becomes a dance with setters and getters. All objects are stupid in themselves, have only a few lines of code and thus becomes easily adaptable to different circumstances and uses. So never create a flag. And instead of trying to make the object intelligent, use the object intelligently. And that code that does this smart thing with the attributes (the state of the object remember?!), put that code in the context (in the methods of the other objects using your object) instead. It is all about keeping stuff generic. - Aramis
![]() ![]() ![]() |
Personal Blog of Aramis Welcome. Filter: Show all, Personal, Programming & Design, Spirit, Economics. There is no particular goal to this blog, but to convey what I find interesting and worth writing about. Get blog as RSS or ATOM .
I never update my twitter feed.
Drive-By Distributed Computing
100218
The Dream Machine
091031
My first GA
091010
Hyper Media
090909
GPS Tag Your Site
090809
OO Instead of Flags
090803
Pool vs Cache
090730
GUI Programming
090704
Brain Computer
081223
Softcoding and Utilities
081115
Throwaway Apps
081027
HTC Dream
081004
J2ME Extends
080911
123
080730
Collaboration
080719
3H Listener
080711
Agent Scripting
080707
Biological Mechanisms
080609
Transitions and GUI
080531
Semantic GUI
080530
Breathing GUI
080529
Diggin
080525
|
||