We've all heard of
the old Decorator Design Pattern (here) or used it at one time or another either directly or indirectly. A decorator is a class that wraps a given abstract class or interface and presents
the same (or a superset) public interface but "decorated" with additional functionality. As a really simplistic example, consider
the System.IO.BufferedStream, it itself is a descendent of System.IO.Stream and wraps
the given stream with buffering logic while still presenting System.IO.Stream's public interface:
1: Stream buffStream = new BufferedStream(rawStream);
Now, let's take a look at a custom-code example. Let's say that we have a class in our data access layer that retrieves a list of products from a database:
1: // a class that handles our CRUD operations for products
2: public class ProductDao
3: {
4: ...
5:
6: // a method that would retrieve all available products
7: public IEnumerable<Product> GetAvailableProducts()
8: {
9: var results = new List<Product>();
10:
11: // must create
the connection
12: using (var con = _factory.CreateConnection())
13: {
14: con.ConnectionString = _productsConnectionString;
15: con.Open();
16:
17: // create
the command
18: using (var cmd = _factory.CreateCommand())
19: {
20: cmd.Connection = con;
21: cmd.CommandText = _getAllProductsStoredProc;
22: cmd.CommandType = CommandType.StoredProcedure;
23:
24: // get a reader and pass back all results
25: using (var reader = cmd.ExecuteReader())
26: {
27: while(reader.Read())
28: {
29: results.Add(new Product
30: {
31: Name = reader["product_name"].ToString(),
32: ...
33: });
34: }
35: }
36: }
37: }
38:
39: return results;
40: }
41: }
Yes, you could use EF or any myriad other choices for this sort of thing, but
the germaine point is that you have some operation that takes a non-trivial amount of time. What if, during
the production day I notice that my application is performing slowly and I want to see how much of that slowness is in
the query versus my code. Well, I could easily wrap
the logic block in a System.Diagnostics.Stopwatch and log
the results to log4net or other logging flavor of choice:
1: // a class that handles our CRUD operations for products
2: public class ProductDao
3: {
4: private static readonly ILog _log = LogManager.GetLogger(typeof(ProductDao));
5: ...
6:
7: // a method that would retrieve all available products
8: public IEnumerable<Product> GetAvailableProducts()
9: {
10: var results = new List<Product>();
11: var timer = Stopwatch.StartNew();
12:
13: // must create
the connection
14: using (var con = _factory.CreateConnection())
15: {
16: con.ConnectionString = _productsConnectionString;
17:
18: // and all that other DB code...
19: ...
20: }
21:
22: timer.Stop();
23:
24: if (timer.ElapsedMilliseconds > 5000)
25: {
26: _log.WarnFormat("Long query in GetAvailableProducts() took {0} ms",
27: timer.ElapsedMillseconds);
28: }
29:
30: return results;
31: }
32: }
In my eye, this is very ugly. It violates Single Responsibility Principle (SRP), which says that a class should only ever have one responsibility, where responsibility is often defined as a reason to change.
This class (and in particular this method) has two reasons to change:
If
the method of retrieving products changes.
If
the method of logging changes.
Well, we could “simplify” this using
the Decorator Design Pattern (here). If we followed
the pattern to
the letter, we'd need to create a base decorator that implements
the DAOs public interface and forwards to
the wrapped instance. So let's assume we break out
the ProductDAO interface into IProductDAO using your refactoring tool of choice (Resharper is great for this).
Now, ProductDao will implement IProductDao and get rid of all logging logic:
1: public class ProductDao : IProductDao
2: {
3: // this reverts back to original version except for
the interface added
4: }
5:
And we create
the base Decorator that also implements
the interface and forwards all calls:
1: public class ProductDaoDecorator : IProductDao
2: {
3: private readonly IProductDao _wrappedDao;
4:
5: // constructor takes
the dao to wrap
6: public ProductDaoDecorator(IProductDao wrappedDao)
7: {
8: _wrappedDao = wrappedDao;
9: }
10:
11: ...
12:
13: // and then all methods just forward their calls
14: public IEnumerable<Product> GetAvailableProducts()
15: {
16: return _wrappedDao.GetAvailableProducts();
17: }
18: }
This defines our base decorator, then we can create decorators that add items of interest, and for any methods we don't decorate, we'll get
the default behavior which just forwards
the call to
the wrapper in
the base decorator:
1: public class TimedThresholdProductDaoDecorator : ProductDaoDecorator
2: {
3: private static readonly ILog _log = LogManager.GetLogger(typeof(TimedThresholdProductDaoDecorator));
4:
5: public TimedThresholdProductDaoDecorator(IProductDao wrappedDao) :
6: base(wrappedDao)
7: {
8: }
9:
10: ...
11:
12: public IEnumerable<Product> GetAvailableProducts()
13: {
14: var timer = Stopwatch.StartNew();
15:
16: var results = _wrapped.GetAvailableProducts();
17:
18: timer.Stop();
19:
20: if (timer.ElapsedMilliseconds > 5000)
21: {
22: _log.WarnFormat("Long query in GetAvailableProducts() took {0} ms",
23: timer.ElapsedMillseconds);
24: }
25:
26: return results;
27: }
28: }
Well, it's a bit better. Now
the logging is in its own class, and
the database logic is in its own class. But we've essentially multiplied
the number of classes. We now have 3 classes and one interface! Now if you want to do that same logging decorating on all your DAOs, imagine
the code bloat! Sure, you can simplify and avoid creating
the base decorator, or chuck it all and just inherit directly. But regardless all of these have
the problem of tying
the logging logic into
the code itself.
Enter
the Interceptors. Things like this to me are a perfect example of when it's good to write an Interceptor using your class library of choice. Sure, you could design your own perfectly generic decorator with delegates and all that, but personally I'm a big fan of Castle's Dynamic Proxy (here) which is actually used by many projects including Moq.
What DynamicProxy allows you to do is intercept calls into any object by wrapping it with a proxy on
the fly that intercepts
the method and allows you to add functionality. Essentially,
the code would now look like this using DynamicProxy:
1: // Note: I like hiding DynamicProxy
behind the scenes so users
2: // don't have to explicitly add reference to Castle's libraries.
3: public static class TimeThresholdInterceptor
4: {
5: // Our logging handle
6: private static readonly ILog _log = LogManager.GetLogger(typeof(TimeThresholdInterceptor));
7:
8: // Handle to Castle's proxy generator
9: private static readonly ProxyGenerator _generator = new ProxyGenerator();
10:
11: // generic form for those who prefer it
12: public static object Create<TInterface>(object target, TimeSpan threshold)
13: {
14: return Create(typeof(TInterface), target, threshold);
15: }
16:
17: // Form that uses type instead
18: public static object Create(Type interfaceType, object target, TimeSpan threshold)
19: {
20: return _generator.CreateInterfaceProxyWithTarget(interfaceType, target,
21: new TimedThreshold(threshold, level));
22: }
23:
24: //
The interceptor that is created to intercept
the interface calls.
25: // Hidden as a private inner class so not exposing Castle libraries.
26: private class TimedThreshold : IInterceptor
27: {
28: //
The threshold as a positive timespan that triggers a log message.
29: private readonly TimeSpan _threshold;
30:
31: // interceptor constructor
32: public TimedThreshold(TimeSpan threshold)
33: {
34: _threshold = threshold;
35: }
36:
37: // Intercept functor for each method invokation
38: public void Intercept(IInvocation invocation)
39: {
40: // time
the method invocation
41: var timer = Stopwatch.StartNew();
42:
43: //
the Castle magic that tells
the method to go ahead
44: invocation.Proceed();
45:
46: timer.Stop();
47:
48: // check if threshold is exceeded
49: if (timer.Elapsed > _threshold)
50: {
51: _log.WarnFormat("Long execution in {0} took {1} ms",
52: invocation.Method.Name,
53: timer.ElapsedMillseconds);
54: }
55: }
56: }
57: }
Yes, it's a bit longer, but notice that:
This class ONLY deals with logging long method calls, no DAO interface leftovers.
This class can be used to time ANY class that has an interface or virtual methods.
Personally, I like to wrap and hide
the usage of DynamicProxy and IInterceptor so that anyone who uses this class doesn't need to know to add a Castle library reference. As far as they are concerned, they're using my interceptor. If I change to a new library if a better one comes along, they're insulated.
Now, all we have to do to use this is to tell it to wrap our ProductDao and it does
the rest:
1: // wraps a new ProductDao with a timing interceptor with a threshold of 5 seconds
2: IProductDao dao = TimeThresholdInterceptor.Create<IProductDao>(new ProductDao(), 5000);
Automatic decoration of all methods! You can even refine
the proxy so that it only intercepts certain methods.
This is ideal for so many things. These are just some of
the interceptors we've dreamed up and use:
Log parameters and returns of methods to XML for auditing.
Block invocations to methods and return default value (stubbing).
Throw exception if certain methods are called (good for blocking access to deprecated methods).
Log entrance and exit of a method and
the duration.
Log a message if a method takes more than a given time threshold to execute.
Whether you use DynamicProxy or some other technology, I hope you see
the benefits this adds. Does it completely eliminate all need for
the Decorator pattern? No, there may still be cases where you want to decorate a particular class with functionality that doesn't apply to
the world at large.
But for all those cases where you are using Decorator to add functionality that's truly generic. I strongly suggest you give this a try!
