An issue that I encounter in developing an editor
Author
Hi,
Currently, I am developing an editor which provides a 3DS-Max-like interface for editing game scenes.
some basic functionals like:
- Camera controls
- Place/Move/Rotate/Scale game objects
- Assign object hierarchy
- Setup attributes of game objects
...
As the UI functionals increased, I soon found that use some state flag like MOVE, ROTATE, SCALE, and write something like:
if(state == MOVE){
//blah blah...
}
else if(state == ROTATE){
//blah blah...
}
the code will soon become very hard to maintain, since we may have tens of buttons changing the behavior of a mouse click.(e.g. the user click on the "Move" button, then one can move an object.)
Having tens of flags and a monster switch statement is obviously a bad idea.
Is there any suggest way to do this?
Thanks!!
GUIs normally heavily rely on design patterns to de-couple code and therefore not make maintenance of code a nightmare. I would suggest you look at patterns such as subject/observer, chain of responsibility, functors, message passing systems.
Quote:Original post by dmail
GUIs normally heavily rely on design patterns to de-couple code and therefore not make maintenance of code a nightmare. I would suggest you look at patterns such as subject/observer, chain of responsibility, functors, message passing systems.
Add the state pattern to that list since it is the pattern which would most likely solve the problem posted.
Quote:Original post by nb
or, um, the simple reply could be "ever heard of 'case' statements?"?
Quote:Original post by southp
a monster switch statement is obviously a bad idea.
yer that'd be right. the one sentence i don't see hidden in there... whatever. i still say 'switch' ftw. just a crap idea while i can be bothered, what about using a pointer to the appropriate function that the mouse data then is pumped to?
Author
Thanks all!
All your opinions are very helpful.
I've just refactored my program. The solution is somehow like message passing system.
The idea is that all the functional are inheritance of the class:
class Handler{
public:
virtual bool HandleRequest(...) = 0;
virtual void Reset();
};
Every Handler is registered to the system with a unique name, and the corresponding widgets, like buttons, will fire a message as this name.
When the system get the message, it then pass the arguments(mostly user inputs in my case) to invoke HandleRequest method of the corresponding Handler, and invoke Reset() method of the previously dominated Handler to do some house-keeping works.
Sorry that I described in plain-text...a UML diagram can tell the whole story. But I don't have appropriate tool to do this right now. This structure seems to work fine for now. I hope it will work 'til the end :D
All your opinions are very helpful.
I've just refactored my program. The solution is somehow like message passing system.
The idea is that all the functional are inheritance of the class:
class Handler{
public:
virtual bool HandleRequest(...) = 0;
virtual void Reset();
};
Every Handler is registered to the system with a unique name, and the corresponding widgets, like buttons, will fire a message as this name.
When the system get the message, it then pass the arguments(mostly user inputs in my case) to invoke HandleRequest method of the corresponding Handler, and invoke Reset() method of the previously dominated Handler to do some house-keeping works.
Sorry that I described in plain-text...a UML diagram can tell the whole story. But I don't have appropriate tool to do this right now. This structure seems to work fine for now. I hope it will work 'til the end :D
Author
Quote:Original post by bombinator-dev
Add the state pattern to that list since it is the pattern which would most likely solve the problem posted.
I later found out that the state pattern may be a much more cleaner solution for my case. But I read your repost after I finished about 60% refactoring :(
I will try it in my future project.
There is always an editor waiting to be implemented on this road :)
Author
Quote:Original post by nb
yer that'd be right. the one sentence i don't see hidden in there... whatever. i still say 'switch' ftw. just a crap idea while i can be bothered, what about using a pointer to the appropriate function that the mouse data then is pumped to?
In fact, this is the first thing I do after I found out that a switch statement was not good enough:)
I believed this was a good way, but I bumped into some problems. The problems I encountered are hard to explain clearly here. Just some architecture things, never mind :)
Quote:Original post by southpQuote:Original post by bombinator-dev
Add the state pattern to that list since it is the pattern which would most likely solve the problem posted.
I later found out that the state pattern may be a much more cleaner solution for my case. But I read your repost after I finished about 60% refactoring :(
I will try it in my future project.
There is always an editor waiting to be implemented on this road :)
Remember there really are not right or wrong solutions here, only different ones with different trade-offs. Some have better trade-offs than others in certain situations. What is nice about using something based on a design pattern is that when you (or your documentation) tells someone that "it's the state pattern" that person then not only knows the static structure of your code but the dynamic behavior and what problem the code is trying to solve. I think the true strength of design patterns are that they provide us with a language with which to discuss design at a higher level.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
