设计模式学习：装饰模式

设计模式原则：对修改关闭，对扩展开放。

单一继承在扩展新的内容时，会修改超类或者修改具体类，违背了这个原则。

举个例子，有一个计算的超类，里面只一个抽象方法CountIntNumber

public abstract class CountNumber
{
public abstract int CountIntNumber(int a,int b);
}

写一个具体的类，用来计算两个数相加：

public class AddNumber:CountNumber
{

public override int CountIntNumber(int a,int b)
{
return a + b;
}

}

测试代码：

public void Start()
{
CountNumber addnumber = new AddNumber();
Debug.Log(addnumber.CountIntNumber(10, 20));
}

测试结果：



如果此时有新的需求，需要计算2个字符串相加，就要更改超类，新增一个抽象方法。或者更改具体类，新增一个字符串相加的方法。当需求总是增加，这种修改很容易造成错误。

下面用装饰者来对需求进行扩展：

/// <summary>
/// 组件的超类
/// </summary>
public abstract class CondimentDecorator:CountNumber
{
public abstract string CountString(string a, string b);
}

在这里，组件类为了和原超类的类型一致，采用了继承。但仍是采用了组合的方式。

下面是具体的组件类：具体的组件在构造函数中指明了要装饰的类。

public class Decorator : CondimentDecorator
{
CountNumber countnumber;

public Decorator(CountNumber _countnumber)
{
this.countnumber = _countnumber;
}

public override string CountString(string a, string b)
{
return a + b;
}

public override int CountIntNumber(int a, int b)
{
return a + b;
}

}

测试：

public void Start()
{
CountNumber addnumber = new AddNumber();
CondimentDecorator decorator = new Decorator(addnumber);
Debug.Log( decorator.CountIntNumber(10, 20));
Debug.Log( decorator.CountString("设计模式： ", "装饰模式"));
}

这样就在不更改的情况下进行扩展。但装饰模式也有缺点，频繁使用会生成很多小类，更加了体量。Java中的I/O有很大部分使用的就是装饰模式。