The Decorator Pattern

Intent: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.*

This post is another love story about software patterns. I love programming to interfaces. Today I am going to talk about one of my favorite benefits of doing this, leveraging the Decorator pattern. What follows is a simple class getting refactored/developed to use the Decorator pattern.

Take for example this simple class:

public class Repository { public void Save(Product product) { // do stuff } }

Lets suppose you want to add logging to this class. What do you do? This maybe?

public class Repository { ILog log = LogManager.GetLogger(typeof(Repository)); public void Save(Product product) { if(log.IsDebugEnabled) log.Debug("Some nifty message here"); // do stuff } }

However, now we have violated the principal of Seperation of Concerns. If we refactor the original class to an interface we get:

public interface Repository { void Save(Product product); }

public class DefaultRepository: Repository { public void Save(Product product) { // do stuff } }

Yes, I did not put an "I" on the interface on purpose. Now that we have the interface we can add this class:

public class LoggingRepositoryDecorator { ILog log = LogManager.GetLogger(typeof(Repository)); Repository _inner;

public LoggingRepositoryDecorator(Repository repository) { this._inner = repository; } public void Save(Product product) { if(log.IsDebugEnabled) log.Debug("Some nifty message here"); this._inner.Save(product); } }

Now we have seperated our concerns (Yea!) and demonstrated the Decorator pattern. You use it like this:

Repository repo = new LoggingRepositoryDecorator(new DefaultRepository);

See how it gets decorated or "wrapped?" The client code has no concept that there is logging involved. If you use some kind of factory to generate the Repositor instance you can turn the logging on and off quite easily by either wrapping or not wrapping the Repository instance. For some examples chech out. You can do alot of infrastrutry things this way, security, logging, tracing, etc. This is also a kind of poorman's AOP.

Also Head First Design Patterns does a great job explaining this pattern.

Random paper about Programming to Interfaces in Java at KSU

This article is part of the GWB Archives. Original Author: Dru Sellers

New on Geeks with Blogs

  • We Won The One Award I Actually Care About

    Full Scale made the Inc. 5000 for the fifth year straight, the 12th listing across my three companies. Here is why the one award you cannot buy is worth stopping for.

  • Your Customers Build the Features Now

    I let a tool I liked sit dead for a year rather than build the features I wanted. An MCP server meant I never had to, and your customers can do the same to your product.

  • Get the Size of a Directory in Linux the Easy Way

    du -sh for the quick answer, ncdu for the cleanup, df for the disk itself: every command for checking directory size in Linux, plus why du and df never agree.

  • Vim Search and Replace: The Ultimate Guide

    One :%s command replaces every match in a file before a find dialog would even open. The Vim substitute patterns worth the muscle memory: flags, ranges, capture groups, and multi-file edits.