one example about interface design of Irrlicht Engine

[jronald]

Code: Select all

IGUIScrollBar* CGUIEnvironment::addScrollBar(bool horizontal, const core::rect<s32>& rectangle, IGUIElement* parent, s32 id)

I found interfaces like this common in the engine, and want to know why not:

Code: Select all

bool CGUIEnvironment::addScrollBar(CGUIScrollBar * scrollbar)

For example, if a color is needed for a scroll bar, in the former case, the addScrollBar interface need be changed, in the latter case, the interface need not be changed.
And with the former, there are always to much parameters in a function.

And I think the benefit of the former design is that, when there are essentially different scroll bars the different implementations could be encapsulated. Otherwise the latter is better than the former in every case, agree?

[CuteAlien]

The implementation classes (like CGUISomething) are not available to users. So that way they couldn't create the scrollbar. But I agree that we shouldn't have all those parameters on creation. It makes code a little bit shorter, but I think it would be better and more readable if all the add functions would be without any parameters. And then parameters would be set later. Maybe I'll add a second set of add functions which do just that one day. Reason is just like you said - too many parameters and the order in which they are added is pretty random (different gui-classes having completely different order of parameters).

[jronald]

The implementation classes (like CGUISomething) are not available to users. So that way they couldn't create the scrollbar. But I agree that we shouldn't have all those parameters on creation. It makes code a little bit shorter, but I think it would be better and more readable if all the add functions would be without any parameters. And then parameters would be set later. Maybe I'll add a second set of add functions which do just that one day. Reason is just like you said - too many parameters and the order in which they are added is pretty random (different gui-classes having completely different order of parameters).

Well, even care the order of parameters.
But I think the add functions should have one/some parameters, for add without some object is incomplete.
The implementation classes are not available to users, but the design is about interfaces, so the design can be decoupled from this issue, agree?

[CuteAlien]

There's 2 things mixed up here. The add is also a factory at the same time to create the object - that's why passing an object won't work (you can't pass the object to a function which is responsible for creating the object). At the same time it's about adding the newly created object to the gui. It's probably not how I would have designed it (there's some problems related to that design), but it works more or less which I prefer to breaking the interface.

[jronald]

There's 2 things mixed up here. The add is also a factory at the same time to create the object - that's why passing an object won't work (you can't pass the object to a function which is responsible for creating the object). At the same time it's about adding the newly created object to the gui. It's probably not how I would have designed it (there's some problems related to that design), but it works more or less which I prefer to breaking the interface.

OK, just discuss the design, break or not, it's up to you.

Code: Select all

IScrollBar * scrool_bar = IScrollBar::create();
scrool_bar->doSomething();
IGUIEnvironment * gui = ...;
gui->add(scrool_bar);

In this way, the sdk user maniplulate the scroll bar object in the same way the IGUIEnvironment do in the the IGUIEnvironment::add(IScroolbar *) function, so that the sdk user than the sdk developer become one.
Maybe the only disadvantage is efficiency by C++ virtual function calls.