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

　　还有一个添加职责的办法，就是利用组合，将原有的对象嵌入到一个新的类中，由此来完成对新职责的添加，例如：

public class SecurityUser
{
private User m_user;
public User User
{
get {return m_user;}
set {m_user = value;}
}
public void SignIn()
{
if (IsValid())
{
m_user.SignIn();
}
else
{
throw new NotAuthorizationException();
}
}
private bool IsValid()
{
//略;
return true;
}
}

　　实现的类图如下：

　　比起继承机制而言，组合方式更加的灵活，尤其当面对User具有自身的继承体系时，如上的设计不需要任何修改，就能从容的应对：

　　此时我们只需要将Employee对象赋给SecurityUser中的User属性就可以实现对Employee权限验证的登录。因此，我们避免了此前采用继承机制所面临的两个问题：

　　1、 类的无限量增加（所谓的“类爆炸”）；

　　2、 权限验证职责的不可重用。

　　然而组合却失去了继承的许多优势，其中，不具备对象的多态特质，就是最大的一个局限。例如，如下创建对象的方式就是错误的：

　　User user = new SecurityUser（）；

　　当一个方法体现为对User的操作时，此时SecurityUser就无法对User类型的对象进行替代，这就限制了软件的可扩展性。例如，在表示层逻辑中，会有一个登录页面将调用SignIn方法：

public class LoginPage
{
public static void SignIn(User user);
}

　　在这种情况下，SecurityUser对象就无法做为参数传入，那么，我们在前面所作的职责添加的努力岂不就是付诸东流了吗？

　　如果仔细观察继承与组合的优劣，我们发现如果将继承机制与组合方式两者结合起来，将会起到意想不到的效果，此时，各自的优点弥补了各自的缺点，完美地解决了“为对象动态添加新的职责”的需求。

　　新的解决方案如下图所示：

　　实际上，如上的类图结构就是设计模式中的Decorator模式，User是被装饰的对象，而SecurityUser则是Decorator，也就是我们所谓的“装饰工”。在这里，SecurityUser是一个具体类，如果有新的装饰需求，例如之前提到的增加日志记录功能，同样需要建立装饰类。此时，对于具体的装饰类而言，具有一些相同的逻辑，在此前提下，可以为其增加一个Decorator抽象类：

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

【责编:John】