The decorator pattern is a pretty straightforward pattern that utilizes wrapping to extend existing classes with new functionality. It’s commonly used to apply cross-cutting concerns on top of business classes, which avoids mixing that up with the business logic. Frameworks like Spring.Net uses this pattern to apply it’s functionality to your classes.
Implementing decorator pattern
The pattern is pretty simple to implement; extract public methods from the class to wrap to an interface and implement that on the decorator. Let the decorator receive an object of the original type and delegate all calls to that object. Let’s look at an example that uses caching (inspired from a discussion with Anders Bratland today on the Swenug MSN group).
The UserService we’ll extend is pretty straight forward;
1: public interface IUserService
2: {
3: User GetUserById(int id);
4: }
5:
6: public class UserService : IUserService
7: {
8: public User GetUserById(int id)
9: {
10: return new User { Id = id };
11: }
12: }
The idea is that we want to cache the user and avoid mixing that logic with the code to retrieve the user. For this we create the decorator wrapper;
1: public class CachedUserService : IUserService
2: {
3: private readonly IUserService _userService;
4:
5: public CachedUserService(IUserService service)
6: {
7: _userService = service;
8: }
9: }
The wrapper implements the same interface as the wrapped class and takes an instance of the wrapped object (in this case the interface to ensure we can add more then one decorator) and store it as an instance variable for later use.
To add our caching, we’ll implement the GetUserById method to first check our cache if the user is there and if not just delegate the call to the wrapped object;
1: private static readonly Dictionary<int, User> UserCache = new Dictionary<int, User>();
2:
3: public User GetUserById(int id)
4: {
5: if (!UserCache.ContainsKey(id))
6: UserCache[id] = _userService.GetUserById(id);
7:
8: return UserCache[id];
9: }
Anyone consuming this service will never have to worry about the caching we just applied, additionally our original code never have to know that it might be cached and each concern can be maintained separately. A win-win on both parts, concerns successfully separated.
Using decorators
Since we need to compose the objects to get all the decorators we want wrapping our object. It’s usually advisable to hide the creation of the object inside a factory. A typical usage could be;
1: public static class ServiceFactory
2: {
3: public static IUserService Create()
4: {
5: var baseObject = new UserService();
6:
7: return new AuditableUserService(new CachedUserService(baseObject))
8: }
9: }
10: .
11: .
12: .
13: private void SetupContext()
14: {
15: _service = ServiceFactory.Create();
16: }
Using this approach we are free to add and subtract as many decorators to the original object as we wish and the consumers never have to know.
Usage scenarios for the decorator pattern
There is several usages for this pattern for a lot of different scenarios not only adding caching to a service. Let’s examine the categories and what they can be used for.
Applying cross cutting concerns
We’ve just seen how we can apply a cross cutting concerns, like caching, to an existing class. The factory hints about Auditing and there is several other you could imagine being interesting. One could be the notorious INotifyPropertyChanged interface that’s needed for data binding. Wrapping the bound object into a decorator that automatically calls the event will keep the domain objects free from infrastructure concerns. Something like;
1: public class NotifyingUser : INotifyPropertyChanged, IUser
2: {
3: private IUser _user;
4: public NotifyingUser(IUser user)
5: {
6: _user = user;
7: }
8:
9: public int Id
10: {
11: get { return _user.Id; }
12: set
13: {
14: _user.Id = value;
15: RaisePropertyChanged("Id");
16: }
17: }
This will keep the user entity clean from data binding concerns and we’ll be able to provide the functionality. Win-Win.
Creating proxies
A lot of frameworks use decorators to create runtime proxies that applies the framework functionality. Spring.Net is an example of that, it uses decorators to apply Mixins and Advices.
Strangle wine refactoring
Michael Feathers talks a lot about how to handle legacy code. One of the concepts I’ve heard him talk about is the “Strangle wine”. A plant that starts out small but if you let it grow it will soon take over and strangle everything else. Refactoring using strangle wine strategies is about replacing legacy code with new code. A variant of decorator pattern can be very useful to accomplish that. In a recent project we refactored from Linq To Sql to NHibernate, not all at once but step by step. To do this successfully we used the ideas behind the decorator (with a touch of the Adapter pattern thrown in there);
1: public class OrderRepository : IOrderRepository
2: {
3: private readonly IOrderRepository _ltsRepository;
4: private readonly IOrderRepository _nhRepository;
5:
6: public OrderRepository(IOrderRepository ltsRepository, IOrderRepository nhRepository)
7: {
8: _ltsRepository = ltsRepository;
9: _nhRepository = nhRepository;
10: }
11:
12: public Order GetOrderById(int id)
13: {
14: var ltsObject = _ltsRepository.GetOrderById(id);
15:
16: return Translator.ToEntityFromLts(ltsObject);
17: }
18:
19: public IListListOrders()
20: {
21: return _nhRepository.ListOrders();
22: }
23: }
This allowed us to move over from Linq to Sql over to NHibernate method by method. Slowly strangling the old repository to death so it could be cut out.
Summary
Decorator pattern is a very versatile pattern with a lot of usage scenarios. A great tool to have in your toolbox. Either as a stand alone pattern or, as we’ve seen in some of the examples, in cooperation with others. It is simple but powerful and I hope you’ll find usages for it in your applications.
#1 by Niclas Nilsson on November 10, 2009 - 08:49
Very nice writeup!
Worth mentioning in this context in concert with the factory may be that a common alternative to the factory is using dependency injection, where the setup code creates the service and it’s decorators once and for all and gives it to the ones who need it. In theory, the factory could still be there in that case too, but I find it more common to just do it in a method in whatever class that wires things up in those case.
Well written!
Kind regards
Niclas Nilsson
#2 by Patrik Löwendahl on November 10, 2009 - 10:36
Thank you Niclas, and a very good point.
It can become troublesome to get all the decorating right so a DI container will defiantly be a great help there.
I still think, as you mention, that the factory is a great help to separate the DI container from the rest of your code though. Could use the common ServiceLocator found on codeplex as well.