views:

974

answers:

4

My previous understanding of the decorator pattern was that you inherit Window with WindowDecorator, then in the overridden methods, do some additional work before calling the Window's implementation of said methods. Similar to the following:

public class Window
{
    public virtual void Open()
    {
     // Open the window
    }
}

public class LockableWindow // Decorator
{
    public virtual void Open()
    {
     // Unlock the window
     base.Open();
    }
}

However this essentially hardcodes the decoration, so how would this be refactored to use composition instead of inheritance?

A: 

The point of the Decorator pattern is to enhance an object with some functionality (e.g. adding buffering to a stream) in a way that's transparent to the caller. In order to use it most effectively, you want to be able to swap in the decorated implementation without refactoring code, which basically implies that you need to maintain the inheritance hierarchy.

What's your actual concern, i.e. what does "this hard-codes the decoration" really mean? What kind of problems do you envision wanting to solve? It may be that decoration is not quite the right approach...

Rob
+4  A: 

Sorry, my C# is a a bit (OK, very) rusty, so there may be a few syntax errors, but the basic idea is right.

public interface IWindow
{
    void Open();
}

public class Window : IWindow
{
    public virtual void Open()
    {
        // Open the window
    }
}

public class LockableWindow : IWindow
{
    public IWindow wrappedWindow;

    public virtual void Open()
    {
        // TODO Unlock window if necessary
        wrappedWindow.open();
    }
}

The key thing to notice is the new IWindow interface; that's what allows you to keep using polymorphism.

Hank Gay
Not that rusty, though virtual is not necessary to implement the interface method
Peter Lillevold
Thanks. I haven't written any since .Net 1.0, actually. It's just that this question didn't need any of the new language features.
Hank Gay
A: 

You simply have your LockableWindow define a constructor that takes an instance of the type, Window, that it will decorate. You could also do it via properties.

public class Window
{    
  public virtual void Open()    
  {        
   // Open the window    
  }
}

public class LockableWindow // Decorator
{    
  private Window window;

  public LockableWindow(Window w)
  {
     window = w;
  }      

  public virtual void Open()    
  {        
    // Unlock the window        
    window.Open();    
  }
}
Mehmet Aras
A: 

My understanding of the decorator pattern is that it is intended to allow a run-time enhancement of an object's capabilities. In the wikipedia explanation, they focus on a component stack for this purpose.

I don't speak C# at all, so this is (obviously) php-ish. It seems that the correct idea would be:

class image{

 function open(){ ... }

} //end of class

class decoratedImage extends image{

 private goodies=array(); //the alleged 'component stack'

 function addGoodie($item){
      $this->goodies[]=$item;
 }

 function open()}{

      parent::open();
      foreach ($this->goodies as $componentClassName){

           $component=new $componentClassName();
           $component->apply($this);

      }

 }

} //end of class

Oh Experienced Ones, please explain the disconnect.

Thanks, tqii

tqwhite