Russian Dolls — metaphor to extend a given functions behavior. Photo borrowed from . Maxpixel To follow good design principles and structure when you develop applications is something I advocate. As the development process goes on we add new functionality to our applications: it could be a feature request from your client or it could be improvements that you’ve suggested. No matter what, these upcoming changes will also change the already given codebase. When changes are introduced we want this to be as easy as possible. In this post I’m going to show you an example of how you can utilize the decorator pattern with the powerful IoC container in scenarios where you want to extend functionality to an existing feature. Autofac Lets say you are about to build a service that serves products. We will call this service and for simplicity we only use one method called . It could look something like this with an implementation connected to it: IProductRepository GetById Normally you would register your concrete implementation XmlProductRepository as IProductRepository with the following code line to support the : dependency inversion principle Lets say that you after a while need some logging when products are fetched. How do you accomplish this? It is tempting to just modify the implementation XmlProductRepository by injecting a logging service like this: But that violates the . The principle states that you are not allowed to modify classes, but you can extend them. Here the decorator pattern is really handy. open/closed principle Instead of cluttering down your original implementation you it by adding a logging proxy, and register it as a decorator of it. extend You will have to modify one code line though, and that one is the registration of the . It will need to be a named registration now so we can refer to it when we register our decorator: original implementation And then connect and register the decorator: The key that we use to refer to the implementation here is . When you have this code in place the first class that will be invoked when you inject your IProductRepository is the LoggingProductRepositoryProxy, and as we have injected the inner implementation to it it will just work as a proxy (russian doll style) following the open/closed principle. productRepository Lets say that you experience your XmlProductRepository slow and you need to cache your products for a while. How would you implement that? It is pretty easy to just add another decorator on top of your logging implementation: Pretty flexible! The decorator pattern in really powerful when it comes to supporting within applications. cross cutting concerns Did you find this post useful? You know what to do! 👏
