.Net中的设计模式——Decorator模式

　　一、模式概述

　　一个场景是我们要为一个对象动态添加新的职责，这个职责并不修改原有的行为，而是在原有行为基础上添加新的功能，就好比装饰工人为一座新居的墙上涂抹上色彩缤纷的颜料一般。

　　从我们拥有的面向对象的知识出发，为一个对象增加新的职责，完全可以利用继承机制，然而再通过实例化派生的子类，来获得新增的职责。由于需要在原有行为基础上添加新功能，此时父类的方法应该为虚方法，例如用户登录行为：

public class User
{
public virtual void SignIn()
{
Console.WriteLine("The User Sign In.");
}
}

　　如果需要为用户登录行为增加权限验证的职责，可以定义一个子类继承User类：

public class SecurityUser:User
{
public override void SignIn()
{
if (IsValid())
{
base.SignIn();
}
else
{
throw new NotAuthorizationException();
}
}
private bool IsValid()
{
//略;
return true;
}
}

　　实现的类图如下：

　　然而继承机制的一个局限是它只能静态地添加对象职责，一旦添加的职责有变，例如客户需求为登录行为添加日志记录功能，虽然我们可以再定义一个子类，重写SignIn（）方法，然而我们却不能控制职责添加的时机与方式。此外，当User具有本身的继承体系时，则其并不能重用SecurityUser的职责。例如，User同时具有另外一个子类Employee，则Employee类的登录行为仍然沿用了其父类User的登录行为，而不具备权限验证的职责。如果需求要求Employee同样要验证登录权限，就必须再为它创建一个子类SecurityEmployee，如图：

　　这样的结果会导致类的数量会随着需求的变化而无限量的增加，同时有关权限验证的职责也没有能够得到充分的重用，这显然违背了面向对象设计的精神。

[1] [2] [3] [4] [5] 下一页

【责编:John】