views:

91

answers:

7

I have a design-pattern question. I have a framework for our smart-client application similar to CAB (Composite Application block), and we call it widget-framework. Where we can define the modules of our application as a "Widget", and there is a config file which lists all the widgets. The widget is any class that implements IWidget interface. All the widget have code to load sub-widgets, and that code is identical. How to share that code among all those widgets, without forcing the widget to inherit from concrete class? What is the best practice in this case? Is there a design pattern for this case?

Thanks

+1  A: 

It sounds like the Decorator pattern could be used to add the 'load sub-widgets' method to each class. That pattern allows for the 'load sub-widgets' method to then be changed for different classes without relying on inheritance.

rosscj2533
A: 

It sounds like the perfect possibility to use a abstract class that inherits from the interface. But it seems that there is a reason to not do this.

You can generate a class that encapsulates all the duplicate code for the widget classes and then create an object of this class in every widget. Now the code is only in one class but every widget can call the functions from his own object to use the functionality of the duplicate code.

Janusz
A: 

I'd do it by aggregation. Make a WidgetLoader class, and use that internally to implement your sub-widget loading functionality.

This keeps the loading functionality decoupled from the main intention of your Widget class, avoids inheritance, and can be made loosely coupled if instantiated via a factory.

ire_and_curses
A: 

If you do not want to extend a super class with the common code you can try to use delegation and wrap the common functionality, let us call it SubWidgetLoader . That is create a class that implements the common functionality and have your IWidget objects contain the SubWidgetLoader. That way each individual Widget does not have to have the code repeated but rather calls on the SubWidgetLoader class to perform the job.

Vincent Ramdhanie
+1  A: 

you can use the composite method, make an object called SubWidgetLoader or something similar, then make all instances of the IWidget contain an instance of the loader class.

GSto
A: 

Why won't you inherit from a base class?

Your situation seem like a good fit for a template method pattern. I think inheritance is the best solution unless there's a really good reason not to. In your specific case, inheriting from BaseWidget seems also the logical step.

Note: I know you specifically ask for how NOT to use inheritance but you don't tell us why. I think, if someone specifically ask for something that's against my usual tendencies for software development he should explain not only what but also why, if he doesn't I reject to simply provide the answer (if I know it) if I think the mere "design" is wrong.

Jorge Córdoba
He's trying to avoid inheriting from a *concrete* base class. This is a good idea, because inheriting from a concrete class is inherently fragile. The base class is unaware that it's internal implementation may be being relied upon. This is a risk - if the base class implementation changes, your inherited class may break. See e.g. http://en.wikipedia.org/wiki/Fragile_base_class.
ire_and_curses
Mmm, I see... there's no day you don't learn something new in stackoverflow... but template method pattern refers specifically to inheriting from a base abstract class, not concrete.
Jorge Córdoba
A: 

Why avoid having them all derive from a common base class? It could be an abstract base class since you are concerned that they not inherit from a concrete base class. The abstract base class could provide the "load sub-widget" functionality that they all share.

But if you're bent on avoiding inheritance, then the Builder pattern seems like a good fit to reuse the code of building up trees of sub-widgets without introducing a base class.

http://en.wikipedia.org/wiki/Builder%5Fpattern

Clay Fowler