本篇文章主要介绍了"Android设计模式之一个例子让你明白彻底装饰者模式decorator pattern"，主要涉及到方面的内容，对于Android开发感兴趣的同学可以参考一下：
导读这篇文章中我不会使用概念性文字来说明装饰者模式，因为通常概念性的问题都很抽象，很难懂，使得读者很难明白到底为什么要使用这种设计模式，我们设计模式的诞生，肯定...
导读
这篇文章中我不会使用概念性文字来说明装饰者模式，因为通常概念性的问题都很抽象，很难懂，使得读者很难明白到底为什么要使用这种设计模式，我们设计模式的诞生，肯定是前辈们在设计程序的时候遇到了某种困难，为了避免这种苦难的发生，从而设计出来的这种设计模式，所以这篇文章中我会带领大家遇见这种困难，从而使用设计模式解决这种困难，最后大家就会明白什么是设计者模式，什么时候应该使用设计者模式以及如何使用设计者模式了
首先我们先来看一下装饰者模式的UML图是什么样子的，图中各个类的含义不懂没有关系，下面我会用一个形象的例子来一一介绍他们，相信大家看完后肯定就明白了
如果不用装饰者设计模式会出现什么问题？
这里我不准备用一些概念性的文字来说明什么是装饰者模式，我就要用一个实际的例子来形象的说明什么是装饰者模式！
比如我们玩网络游戏，我们都要先创建一个角色对吧，这些角色每个人创建出来的都不一样，因为角色肯定可以根据用户的审美来个性化打造，但是每个角色最开始的能力都是一样的，不会因为一个玩家给他捏了一张特别帅的脸而变得特别的厉害。那么这个角色肯定是一个接口，这就是UML图中的Conponent接口
/**
* 游戏角色
*/publicinterfaceAvatar {void describe();
}
非常简单，只有一个方法，我们只用来演示，真正的游戏角色不可能只有这么简单。describe方法用来描述这个角色。
好，我们玩游戏肯定有职业对吧，假设我们这款游戏只设计了4种职业：战士（Worrior），法师（Mage），猎人（Hunter），术士（Warlock）。我们要创建4个实现类，这就对应ConcreteComponent类
publicclassWorriorimplementsAvatar {@Overridepublic String describe() {
return"战士";
}
}
publicclassMageimplementsAvatar {@Overridepublic String describe() {
return"法师";
}
}
publicclassHunterimplementsAvatar {@Overridepublic String describe() {
return"猎人";
}
}
publicclassWarLockimplementsAvatar {@Overridepublic String describe() {
return"术士";
}
}
好了，现在我们已经创建好4种职业的游戏角色了。现在我们的玩家觉得太单调了，所有同样职业的角色都长一个样子，你们应该允许我们在创建角色的时候可以修改角色的外观。比如选择头发颜色。
这可怎么办，我们有4种职业啊，每种职业提供3种颜色的头发，我们得再创建12个子类啊，而且之前设计的4个实现类的作用也就不大了，因为大家肯定都去改变一下头发的颜色。好，先硬着头皮来写吧。
publicclassWorriorWithRedHairimplementsAvatar{@Overridepublic String describe() {
return"战士+红颜色头发";
}
}
publicclassWorriorWithGreenHairimplementsAvatar{@Overridepublic String describe() {
return"战士+绿颜色头发";
}
}
publicclassWorriorWithBlueHairimplementsAvatar{@Overridepublic String describe() {
return"战士+蓝颜色头发";
}
}
publicclassMageWithRedHairimplementsAvatar{@Overridepublic String describe() {
return"法师+红颜色头发";
}
}
publicclassMageWithGreenHairimplementsAvatar{@Overridepublic String describe() {
return"法师+绿颜色头发";
}
}
publicclassMageWithBlueHairimplementsAvatar{@Overridepublic String describe() {
return"法师+蓝颜色头发";
}
publicclassHunterWithRedHairimplementsAvatar{@Overridepublic String describe() {
return"猎人+红颜色头发";
}
}
publicclassHunterWithGreenHairimplementsAvatar{@Overridepublic String describe() {
return"猎人+绿颜色头发";
}
}
publicclassHunterWithBlueHairimplementsAvatar{@Overridepublic String describe() {
return"猎人+蓝颜色头发";
}
publicclassWarLockWithRedHairimplementsAvatar{@Overridepublic String describe() {
return"术士+红颜色头发";
}
}
publicclassWarLockWithGreenHairimplementsAvatar{@Overridepublic String describe() {
return"术士+绿颜色头发";
}
}
publicclassWarLockWithBlueHairimplementsAvatar{@Overridepublic String describe() {
return"术士+蓝颜色头发";
}
好了，加班到半夜，终于写完了。第二天上班，老板来找你了，现在我们的玩家越来越多了，他们反映说我们的角色还是太单调，我们还要让玩家可以选择上衣的颜色和裤子的颜色，上衣有5种颜色，裤子有5种颜色。听完这个需求，我想你也应该吐血了。比如玩家A会选择战士+红色头发+白色上衣+蓝色裤子，玩家B会选择术士+蓝色头发+白色上衣+黄色裤子。这组合也太多了，这得写多少个实现类。这种方法肯定是行不通的。
使用装饰者模式如何解决问题？
这时公司来了个大牛，他听说了这个情况，接下了这个需求，你心想他一定是疯了，可是第二天他就完成了任务，你吃了一大惊，赶紧去看他的代码是怎么实现的，原来这位大牛使用了你连听都没说过的装饰者设计模式。
首先他设计了一个类，实现了Avatar接口，并且传入了一个Avatar对象，这就对应UML图中的Decorator
