装饰器模式是一种将给定接口的基本实现作为扩展其行为而不修改原始实现的机制。
它类似于从基类继承,但它具有更大的灵活性。例如,装饰器类可以应用于实现相同接口的任何其他类,没有限制只扩展单个基类。它们也可以链接在一起等...
例如
public interface IThing
{
void AMethod()
}
public abstract class ThingDecorator : IThing
{
private IThing inner;
public ThingDecorator(IThing inner)
{
this.inner = inner;
}
public virtual void AMethod()
{
this.inner.AMethod();
}
}
从 ThingDecorator 继承并将您自己的扩展应用到虚拟 AMethod 将添加行为(装饰)传入的内部实例。由于内部实例与接口耦合,它可以是该接口的任何实现。
在您的示例中,您可以将 ThingDecorator 继承为 AuditThingDecorator,并在调用 base.AMethod() 之前覆盖 AMethod 并包含审核功能
这与仅将属性应用于类不同。我认为您正在尝试使用属性应用行为。如果存在容器或系统的其他部分可以读取属性并实际应用给定行为,则属性只能将行为应用于类。使用 DataAnnotations,还有其他类可以读取这些属性并应用行为(例如,在 ASP.NET MVC 中,DefaultModelBinder 使用某些属性在绑定模型时提供验证)。
这是一种 AOP(面向apsect 的编程)方法。应用它的一种方法(也是我倾向于使用的一种方法)是使用 Castle.Core 并创建可以自动实现接口方法或扩展虚拟方法并从正在拦截的方法/属性中读取属性的拦截器,然后应用行为:
http://docs.castleproject.org/Tools.DynamicProxy-Introduction.ashx
它们本质上都是给定类型的代理,但是上面的装饰器模式不是动态的,它们是在代码中创建的,AOP 方法可以在运行时应用行为。