using the decorator design pattern to address cross-cutting concerns
DESCRIPTION
Presented 2013-07-15 to the VT .NET user groupTRANSCRIPT
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