views:

123

answers:

2

I'm designing GUI (graphical user interface) system for a game engine (C++).

Idea is to create a heirarchy of GUI controllers like Focusable, Hoverable, Dragable etc. Every GUI component can attach multiple controllers, they modify component's behaviour.

I think it gives flexible system and protects from code duplication. Different instances of the same GUI class can have different complex behaviours (may be, even change it dynamically), so this approach looks practical.

The other choice is to add focused, hovered, dragged etc. flags in the base GUI component class. It looks like overhead and not that flexible.

Another solution is to use Decorator pattern and wrap objects with FocusDecorator, HoverDecorator etc. Maintaining such system looks a bit harder.

Question: What are pitfalls in my solution? May be you have seen a better approaches in GUI systems? What are the best ways of implementing such flexible complex system?

A: 

Why not solve the problem of varying component behaviors with the "Strategy" pattern?

miquelramirez
GUI component can be focused and hovered in the same time OR only focused OR only hovered. Another can be only dragged. It looks like GUI component can have many strategies in the same time. Or at least one Composite Strategy.
topright
From what you say, it seems to me you have two sources of variation in behavior: how the user input is handled and how the widget is actually represented on screen. Do you foresee you would have combinations of strategies for both aspects at the same time?
miquelramirez
Yes, controller (aspect) reflects on both user input processing and view. Client code looks like: component.addController( focusable ); ... focusable has slots and connects to component's signals onKeyUp, onPaint etc.
topright
I'd go for the Strategy, looks to me the one that fits the best your problem. For starters. As happens with any design, it will be evolving anyways :)
miquelramirez
A: 

Your solution is quite good, to be honest, I think it is exactly what the Decorator design pattern is about, however in C++ you have better implementation techniques at hand. You can easily use policy based design to create GUI component template class and add component behaviour trait classes as its arguments and then inherit from the arguments.

Gabriel Ščerbák
Thank you, template-based implementation really is preferable in most cases. But may be script-driven construction of GUI components can become more flexible with this dynamic (a la multi-pimpl) implementation.
topright