How to use pure interface based programming to implement a GUI library.

It is recommend to use pure interface based programming approach, and it use interface inherit only. I wonder to know whether is it a good way to implement any kind of program.

For example I consider how to design a GUI library without any implement inherit, but find it will become hard to extend.
For example we have a set of interface and implement classes:

class IWidget{};
class IButton : public IWidget{};
class ILable : public IWidget{};
class Button : public IButton{}
class Lable : public ILable{};

Then the implement class Button and Label must have a lot of code is the same, as then should put into Widget class in usual design. There has a way is put the common code into another class, for example class WidgetImplHelper, and the Button and Lable hold an instance of WidgetImplHelper, forward each interface call to the helper instance. It is really a heavy burden to code so much function that just a forward call.

Consider we want our GUI library satisfy the Open Closed Principle, that mean we want out client can expend out widget easily. For the other library can only see the interface of our library, they can not use our helper classes. So if they just want to expend ILabel and replace the paint function, they need rewrite all the interface functions.

Is there any suggestion about this?
- If you want to have a function for a class that can be overwritten\replaced then that function should be made virtual. This with Inheritence should satisfy the Open/closed principle based on the first paragraph of it's description in Wikipedia.

- I don't actually see how you would have to write a lot of code just to inherit functions from another class. That's actually the opposite of true so I suspect I'm misunderstanding what you are saying here. I also don't understand what you mean by "forward the call", I suspect this has something to do with the way you want to isolate your functions but I would need to you either explain this in more detail or offer an example.
Well, if I understood correctly, I can tell you that you can have both: A set of interfaces AND base classes. There is a catch, though:

1
2
3
4
5
6
7
8
9
class IWidget { ... };
class WidgetImpl : public IWidget { ... };
class IButton : public IWidget { ... };
class ButtonImpl : public IButton { ... }; //WAIT!!! Why not WidgetImpl??  Ok...
class ButtonImpl : public IButton, public WidgetImpl { ... } //WAIT!!!  This one doesn't seem to work!  Compiler says I haven't implemented IWidget.  Ok...
//Redo WidgetImpl:
template<class T>
class WidgetImpl : public T { ... };
class ButtonImpl : public WidgetImpl<IButton> { ... }; //Finally!!! 


If you inherit multiple times a class, you have multiple implementations of that class. The above method of inheriting from a templated class is quite efficient; I learned it studying ATL, and I therefore call it "รก la ATL".
Thanks all of you, sorry for my native language I am not good at English.

In fact I want devide my library into several shared libraries, and I don't want them link togather, but using dynamic load like LoadLibrary in win32 or dlopen in linux. Maybe it is like a plugin system from the concept of OSGi.

That mean two shared libraries can only comnicate with each other with pure interface. So one library can not see any implement code. So one library can neither instancing the class in other library on the stack, nor inheriting a class which is not a pure interface.

This is also the problem that COM mit, the ATL is a way to resolve this. In fact it is simply put the implement code into header file(as a template). I really worry this method will cause heavy compile dependency, of course I am not familiar with ATL, maybe my worry is unnecessary.
Topic archived. No new replies allowed.