设计模式之装饰模式

    装饰模式(Decorator Pattern)允许向一个现有的对象添加新功能，同时又不改变其结构。这种类型的设计模式属于结构型模式（结构型模式设计，它关注类和对象的组合。继承这一概念被用来组合接口和定义组合对象获得新功能的方式。它包括以下几种具体的设计模式：适配器模式、桥接模式、过滤器模式、组合模式、装饰模式、外观模式、享元模式和代理模式。），它是作为现有的类的一个包装。这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。

    装饰模式动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更加灵活。

    装饰模式应用的场景：

    当系统需要新功能的时候，如果向旧的类中添加新的代码，这些新的代码通常是装饰了原有类的核心职责或主要行为，但是它们在主类中加入了新的字段，新的方法和新的逻辑，从而增加了主类的复杂度，而这些新加的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。这种时候装饰模式就提供了一个很好的解决方案，它把每个需要装饰的功能单独放在单独的类中，并让这个类包装它所需要的装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象了。

    举个栗子，奇迹暖暖换装游戏可以根据每个人的喜欢给玩偶换上喜欢的衣服。如果不考虑设计模式，按照传统的编码思路，首先会写一个Person基类，接着Person基类如果不能满足要求(基本上不满足)，比如要给Person的基础上穿一件T恤，我们就会写一个TShirtPerson去继承Person基类，返回新的人物形象；现在又想换成裙子，那么就又需要写一个DressPerson来继承Person基类，以此类推。虽然可以解决问题，但是这样层层继承，子类会膨胀，耦合性太强。

    那么我们换种思路，既然游戏人物可以换各种各样的服装，但它的本质依然是一个人物形象，换的服装只是它附加的一种属性。按照面向对象的思想，既然附加的服装属性有很多，那么我们可以把服装属性单独抽取成一个父类服装对象(也就是先不管人物形象，只针对附加的服装，这样做的好处是低耦合，解决子类过于膨胀的问题)，让各种各样的服装分别继承服装基类即可；因此我们也就可以这样定义，Person就是我们的核心组件，各种服装是我们的装饰者。

 

    那么我们可以写一个Demo来模拟以上的奇迹暖暖换装游戏。

    首先是Person类，这是我们的核心组件。这里我们分成了man和woman两种形象。

      

 

    核心组件完成以后，我们就来完成附加的服装类。服装类这里设计了上衣、裤子、鞋子和裙子作为选择。

 

 

 

 

 

    最后我们用了一个DressUp类来实现换装。

 

 

 

 最后效果

 

 代码下载：https://download.csdn.net/download/dzhongjie/11545407。