我要评论一、动机（motivate）
在房子装修的过程中，各种功能可以相互组合，来增加房子的功用。类似的，如果我们在软件系统中，要给某个类型或者对象增加功能，如果使用“继承”的方案来写代码，就会出现子类暴涨的情况。比如：imarblestyle是大理石风格的一个功能，ikeepwarm是保温的一个接口定义，ihousesecurity是房子安全的一个接口，就三个接口来说，house是我们房子，我们的房子要什么功能就实现什么接口，如果房子要的是复合功能，接口不同的组合就有不同的结果，这样就导致我们子类膨胀严重，如果需要在增加功能，子类会成指数增长。这个问题的根源在于我们“过度地使用了继承来扩展对象的功能”，由于继承为类型引入的静态特质（所谓静态特质，就是说如果想要某种功能，我们必须在编译的时候就要定义这个类，这也是强类型语言的特点。静态，就是指在编译的时候要确定的东西；动态，是指运行时确定的东西），使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀（多继承）。如何使“对象功能的扩展”能够根据需要来动态（即运行时）地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？
二、意图（intent）
动态地给一个对象增加一些额外的职责。就增加功能而言，decorator模式比生成子类更为灵活。 —— 《设计模式》gof
三、结构图（structure）
四、模式的组成
在装饰模式中的各个角色有：
（1）、抽象构件角色（component）：给出一个抽象接口，以规范准备接收附加责任的对象。
（2）、具体构件角色（concrete component）：定义一个将要接收附加责任的类。
（3）、装饰角色（decorator）：持有一个构件（component）对象的实例，并实现一个与抽象构件接口一致的接口。
（4）、具体装饰角色（concrete decorator）：负责给构件对象添加上附加的责任。
五 、装饰模式的具体代码实现
继续拿盖房子来说事吧。
/// <summary>
/// 该抽象类就是房子抽象接口的定义，该类型就相当于是component类型，是饺子馅，需要装饰的，需要包装的
/// </summary>
public abstract class house
{
public abstract void renovation();//房子的装修方法--该操作相当于component类型的operation方法
}
/// <summary>
/// 该抽象类就是装饰接口的定义，该类型就相当于是decorator类型，如果需要具体的功能，可以子类化该类型
/// </summary>
public abstract class decorationstrategy : house //关键点之二，体现关系为is-a，有这这个关系，装饰的类也可以继续装饰了
{
//通过组合方式引用decorator类型，该类型实施具体功能的增加这是关键点之一，包含关系，体现为has-a
protected house _house;
protected decorationstrategy(house house)//通过构造器注入，初始化平台实现
{
this._house = house;
}
public override void renovation() //该方法就相当于decorator类型的operation方法
{
if (this._house != null)
{
this._house.renovation();
}
}
}
/// <summary>
/// patrickliu的房子，我要按我的要求做房子，相当于concretecomponent类型，这就是我们具体的饺子馅，我个人比较喜欢韭菜馅
/// </summary>
public sealed class myhouse : house
{
public override void renovation()
{
console.writeline("装修patrickliu的房子");
}
}
/// <summary>
/// 具有安全功能的设备，可以提供监视和报警功能，相当于concretedecoratora类型
/// </summary>
public sealed class housesecuritydecorator : decorationstrategy
{
public housesecuritydecorator(house house) : base(house) { }
public override void renovation()
{
base.renovation();
console.writeline("增加安全系统");
}
}
/// <summary>
/// 具有保温接口的材料，提供保温功能，相当于concretedecoratorb类型
/// </summary>
public sealed class keepwarmdecorator : decorationstrategy
{
public keepwarmdecorator(house house) : base(house) { }
public override void renovation()
{
base.renovation();
console.writeline("增加保温的功能");
}
}
public class program
{
static void main()
{
house myselfhouse = new myhouse();//这就是我们的饺子馅，需要装饰的房子
decorationstrategy securityhouse = new housesecuritydecorator(myselfhouse);
securityhouse.renovation();
//房子就有了安全系统了
//如果我既要安全系统又要保暖呢，继续装饰就行
decorationstrategy securityandwarmhouse = new housesecuritydecorator(securityhouse);
securityandwarmhouse.renovation();
}
}六、装饰模式的实现要点：
- 通过采用组合、而非继承的手法，decorator模式实现了在运行时动态地扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。
- component类在decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且decorator类对于component类应该透明——换言之component类无需知道decorator类，decorator类是从外部来扩展component类的功能。
- decorator类在接口上表现为is-a component的继承关系，即decorator类继承了component类所具有的接口。但在实现上又表现为has-a component的组合关系，即decorator类又使用了另外一个component类。我们可以使用一个或者多个decorator对象来“装饰”一个component对象，且装饰后的对象仍然是一个component对象。
- decorator模式并非解决“多子类衍生的多继承”问题，decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。
1、装饰模式的优点：
- 把抽象接口与其实现解耦。
- 抽象和实现可以独立扩展，不会影响到对方。
- 实现细节对客户透明，对用于隐藏了具体实现细节。
2、装饰模式的缺点：
- 增加了系统的复杂度
3、在以下情况下应当使用桥接模式：
- 如果一个系统需要在构件的抽象化角色和具体化角色之间添加更多的灵活性，避免在两个层次之间建立静态的联系。
- 设计要求实现化角色的任何改变不应当影响客户端，或者实现化角色的改变对客户端是完全透明的。
- 需要跨越多个平台的图形和窗口系统上。
- 一个类存在两个独立变化的维度，且两个维度都需要进行扩展。
七、.net 中装饰模式的实现
在net框架中，有一个类型很明显的使用了“装饰模式”，这个类型就是stream。stream类型是一个抽象接口，它在system.io命名空间里面，它其实就是component。filestream、networkstream、memorystream都是实体类concretecomponent。右边的bufferedstream、cryptostream是装饰对象，它们都是继承了stream接口的。
如图：
stream就相当于component，定义装饰的对象，filestream就是要装饰的对象，bufferedstream是装饰对象。我们看看bufferedstream的定义，部分定义了。
public sealed class bufferedstream : stream
{
private const int _defaultbuffersize = 4096;
private stream _stream;
}到此这篇关于.net结构型设计模式之装饰模式（decorator）的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持代码网。
发表评论