using the decorator design pattern to address cross-cutting concerns

Rob Hale

VT .NET User Group

July 15, 2013

Common functionality that spans layers and tiers. Examples are operations like:

authentication

authorization

caching

communication

exception management

validation

logging

Demo: TypicalExample

Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

A responsibility is a reason to change, and a class or module should have one, and only one, reason to change.

public void Execute()

{

Logger.Info("Starting execution");

Console.WriteLine("We're doing our job!");

Logger.Info("Done execution");

}

Two responsibilities:

Logging

Processing

Demo: DependencyInjection

The good news

Processor is more loosely coupled

The bad news

Processor still has two responsibilities

IComponent + Operation()

ConcreteComponent + Operation()

Decorator - iComponent + Operation()

ConcreteDecorator - iComponent + Operation()

Demo: DecoraterExample

http://www.dofactory.com/Patterns/PatternDecorator.aspx ◦ Check out the “real world” example