0

No doubt that decorator pattern is good and easy standard to enhance some method in class which can't (or shouldn't) inherit the one with old method, like in this example in C# (I am not using interface (I should) to make it as short as possible).

using System; class Human { ... } class Father { public string Info() { return "John"; } } class Son : Human { // decorating Father Father f = new Father(); public string Info() { return "I am son of "+f.Info(); } } class Program { public static void Main() { Son s = new Son(); Console.WriteLine(s.Info()); // I am son of John Console.ReadKey(); } } 

But since we have multiple inheritance in C++, we can hide Fathers' Info() instead of decorate it:

#include <string> #include <iostream> using namespace std; class Human { ... }; class Father { public: string Info() { return "John"; } }; class Son : public Human, Father { // inherit both public: string Info() { return "I am son of " + Father::Info(); } }; int main() { Son* s = new Son(); cout << s->Info(); // I am son of John cin.get(); return 0; } 

I understand that the reason for many patterns is to move the ad-hoc logic from reusable class to ad-hoc class, so the reusable class does not need to be (or can't be) messed with ad-hoc code. But this can be achieved with multiple inheritance, too.

So can you explain (or give an example) where decoration is better idea than multiple inheritance?

2
  • I guess the common example is Digital Signal Processing. You want to compose processors dynamically rather than define them by a static inheritance hierarchy. Commented Feb 22, 2012 at 10:24
  • When you have multiple inheritance, you can use it. Commented Feb 22, 2012 at 10:25

2 Answers 2

4

With the decorator pattern you can decorate objects at run-time, while multiple inheritance is a compile-time solution. This allows you to freely combine different decorators with minimal overhead, whereas with multiple inheritance, you need a new class for each combination of decorators.

Also, multiple inheritance is hard to get right if you are inheriting anything but interface-classes (classes that only have pure virtual methods).

Sign up to request clarification or add additional context in comments.

1 Comment

@JanTuroň: It's not just compilation time. With multiple inheritance you need to write a new class for each combination of decorators you might want to use. This results in a lot of overhead code-wise. Decorators can freely be combined with minimal overhead, since they are agnostic of what they decorate, as long as the interface fits.
0

In my opinion, this is not the decorator pattern and you seem to be using inheritance the wrong way. Before inheriting, ask yourself, if the statement holds true: "Son is a Father" or SpecificObject is a GeneralizedObject, which is not what you ment to express.

The decorator pattern works by passing the object to be decorated to the object that decorates it. A typcial example is the BorderClass in Gui's that decorates the widget you pass it with a border.

 public class Border : Widget { public Border(Widget decorateMe) { this._toDecorate = decorateMe; } public virtual void draw(gc or whatnot){ gc.drawRectangle(blah); this._toDecorate.draw(gc); } } 

hope this helps

2 Comments

I know, I know - the names of my classes - Father and Son - are a little misleading. Maybe I should have used another names and methods... too late now.
and i wanted to make obvious that a class can't decorate itsself from within, the thing to be decorated is passed to it.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.