文章目录装饰模式结构实现透明与半透明透明装饰模式半透明装饰模式特点装饰模式装饰模式Decorator Pattern可以在不创建更多子类的情况下让对象功能得以扩展,即可以在不改变一个对象本身功能的基础上给对象增加额外的新行为在现实生活中这种情况也到处存在。例 如 一 张 照 片 我 们 可 以 不 改 变 照 片 本 身 给 它 增 加 一 个 相 框 使 得 它 具 有 防 潮 的功 能 而 且 用 户可 以 根 据 需 要 给 它 增 加 不 同 类 型 的 相 框 甚 至 可 以 在 一 个 小 相 框 的外 面 再 套 一 个 大 相 框 。装饰模式是一种用于替代继承的技术它通过一种无须定义子类的方式来给对象动态增加职责使用对象之间的关联关系取代类之间的继承关系。在装饰模式中引入了装饰类在装饰类中既可以调用待装饰的原有类的方法还可以增加新的方法以扩充原有类的功能。在面向对象编程中装饰模式是一种设计模式它允许将行为静态或动态地添加到单个对象中而不会影响同一类中其他对象的行为。装饰器模式对于遵守单一责任原则通常是有用的因为它允许将功能划分到具有独特关注区域的类之间。动态的给一个对象增加一些额外的职责。就扩展功能而言装饰器模式提供了一种比使用子类更灵活的方式。结构在装饰模式结构图中包含如下几个角色Component抽象构件它是具体构件和抽象装饰类的共同父类声明了在具体构件中实现的业务方法它的引入可以使客户端以一致的方式处理未被装饰的对象以及装饰之后的对象实现客户端的透明操作。Concrete Component具体构件它是抽象构件类的子类用于定义具体的构件对象实现了在抽象构件中声明的方法装饰器可以给它增加额外的职责方法。Decorator抽象装饰类它也是抽象构件类的子类用于给具体构件增加职责但是具体职责在其子类中实现。它维护一个指向抽象构件对象的引用通过该引用可以调用装饰之前构件对象的方法并通过其子类扩展该方法以达到装饰的目的。Concrete Decorator具体装饰类它是抽象装饰类的子类负责向构件添加新的职责。每一个具体装饰类都定义了一些新的行为它可以调用在抽象装饰类中定义的方法并可以增加新的方法用以扩充对象的行为。实现// 战士的抽象类classSoldier{public:Soldier(){}Soldier(string name):m_name(name){}stringgetName(){returnm_name;};virtualvoidfight()0;virtual~Soldier(){}protected:string m_namestring();};// 黑胡子(Marshall·D·Teach)classTeach:publicSoldier{public:usingSoldier::Soldier;voidfight()override{coutm_name依靠惊人的力量和高超的体术战斗...endl;}};// 抽象的恶魔果实//在DevilFruit 类中没有重写父类Soldier的纯虚函数fight()所以它还是抽象类//恶魔果实有很多种类每种恶魔果实能力不同所以战斗方式也不同//因此需要在恶魔果实的子类中根据每种果实能力去重写作战函数fight()的行为。classDevilFruit:publicSoldier{public:// 指定要给哪个人吃恶魔果实 -- 附魔voidenchantment(Soldier*soldier){m_humansoldier;m_namem_human-getName();}virtual~DevilFruit(){}protected:Soldier*m_humannullptr;};// 暗暗果实classDarkFruit:publicDevilFruit{public:voidfight()override{//在重写父类的fight()函数的时候用当前恶魔果实能力和战士的自身能力进行了加成//调用了战士对象的作战函数 m_human-fight()在原有基础上提升了其战斗力。m_human-fight();// 使用当前恶魔果实的能力coutm_human-getName()吃了暗暗果实, 可以拥有黑洞一样的无限吸引力...endl;warning();}private://根据实际需要定义类独有的方法voidwarning(){coutm_human-getName()你要注意: 吃了暗暗果实, 身体元素化之后不能躲避攻击会吸收所有伤害!endl;}};// 震震果实classQuakeFruit:publicDevilFruit{public:voidfight()override{m_human-fight();coutm_human-getName()吃了震震果实, 可以在任意空间引发震动, 摧毁目标...!endl;}};// 大饼果实classPieFruit:publicDevilFruit{public:voidfight()override{m_human-fight();coutm_human-getName()吃了大饼果实, 获得大饼铠甲...!endl;ability();}voidability(){cout最强辅助 -- 大饼果实可以将身边事物变成大饼, 帮助自己和队友回血...endl;}};intmain(){Teach*teachnewTeach(马歇尔·D·蒂奇);DarkFruit*darknewDarkFruit;QuakeFruit*quakenewQuakeFruit;PieFruit*pienewPieFruit;// 黑胡子吃了暗暗果实dark-enchantment(teach);// 黑胡子又吃了震震果实quake-enchantment(dark);// 黑胡子又吃了大饼果实pie-enchantment(quake);// 战斗//调用最外层的属性会调用所有属性pie-fight();deleteteach;deletedark;deletequake;deletepie;return0;}透明与半透明特性透明装饰模式半透明装饰模式基类一致性所有的装饰器只实现基类的虚函数。装饰器可以增加基类没有的特有方法如font stylecolor:rgb(68, 71, 70);ability()/font。客户端写法font stylecolor:rgb(68, 71, 70);Soldier* s new PieFruit(new Teach());/fontfont stylecolor:rgb(68, 71, 70);PieFruit* p new PieFruit(); p-enchantment(...);/font优点客户端可以完全无差别地对待所有对象。更加灵活可以调用装饰器独有的功能。缺点无法调用装饰器新增的功能。客户端必须知道它正在处理的是哪个具体的装饰器。透明装饰模式在透明装饰模式中要求客户端完全针对抽象编程装饰模式的透明性要求客户端程序不应该将对象声明为具体构件类型或具体装饰类型而应该全部声明为抽象构件类型。对于客户端而言具体构件对象和具体装饰对象没有任何区别。也就是应该使用如下代码Component*c1newConcreteComponent();Component*c2newConcreteDecorator(c1);而不应该使用如下代码ConcreteComponent*c1newConcreteComponent();ConcreteDecorator*c2newConcreteDecorator(c1);透明装饰模式可以让客户端透明地使用装饰之前的对象和装饰之后的对象无须关心它们的区别此外还可以对一个已装饰过的对象进行多次装饰得到更为复杂、功能更为强大的对象。半透明装饰模式透明装饰模式的设计难度较大而且有时我们需要单独调用新增的业务方法。为了能够调用到新增方法我们不得不用具体装饰类型来定义装饰之后的对象而具体构件类型还是可以使用抽象构件类型来定义这种装饰模式即为半透明装饰模式。也就是说对于客户端而言具体构件类型无须关心是透明的但是具体装饰类型必须指定这是不透明的。Component*c1newConcreteComponent();ConcreteDecorator*c2newConcreteDecorator(c1);c2.operation();c2.addFunc();半透明装饰模式可以给系统带来更多的灵活性设计相对简单使用起来也非常方便但是其最大的缺点在于不能实现对同一个对象的多次装饰而且客户端需要有区别地对待装饰之前的对象和装饰之后的对象。特点注意事项**尽量保持装饰类的接口与被装饰类的接口相同**这样对于客户端而言无论是装饰之前的对象还 是装饰之后的对象都可以一致对待。这也就是说在可能的情况下我们应该尽量使用透明装饰式。**尽量保持具体构件类ConcreteComponent是一个“轻”类**也就是说不要把太多的行为放在具体构件类中我们可以通过装饰类对其进行扩展。如果只有一个具体构件类那么抽象装饰类可以作为该具体构件类的直接子类。主要优点对于扩展一个对象的功能装饰模式比继承更加灵活性不会导致类的个数急剧增加。可以通过一种动态的方式来扩展一个对象的功能通过配置文件可以在运行时选择不同的具体装饰类从而实现不同的行为。可以对一个对象进行多次装饰通过使用不同的具体装饰类以及这些装饰类的排列组合可以创造出很多不同行为的组合得到功能更为强大的对象。具体构件类与具体装饰类可以独立变化用户可以根据需要增加新的具体构件类和具体装饰类原有类库代码无须改变符合“开闭原则”。主要缺点使用装饰模式进行系统设计时将产生很多小对象这些对象的区别在于它们之间相互连接的方式有所不同而不是它们的类或者属性值有所不同大量小对象的产生势必会占用更多的系统资源在一定程序上影响程序的性能。装饰模式提供了一种比继承更加灵活机动的解决方案但同时也意味着比继承更加易于出错排错也很困难对于多次装饰的对象调试时寻找错误可能需要逐级排查较为繁琐。适用环境在不影响其他对象的情况下以动态、透明的方式给单个对象添加职责。当不能采用继承的方式对系统进行扩展或者采用继承不利于系统扩展和维护时可以使用装饰模式。不能采用继承的情况主要有两类第一类是系统中存在大量独立的扩展为支持每一种扩展或者扩展之间的组合将产生大量的子类使得子类数目呈爆炸性增长第二类是因为类已定义为不能被继承如final 类。