装饰模式

DesignPattern 项目地址： youlookwhat/DesignPattern 简介： Java 设计模式归纳 (观察者、工厂、单例、策略、适配器、命令、装饰者、外观、模板方法、状态). 更多： 作者 提 Bug 标签： 参照 Hongyang 的 CSDN 博客所写。如有错误欢迎指正，如有侵权，请联系我删除。 Java 设计模式（观察者模式、工厂模式、单例模式、策略模式、命令模式、装饰者模式、外观模式、模板方法模式、状态模式） 设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。 设计模式分为三种类型，共 23 种： 创建型模式 ： 单例模式 、抽象工厂模式、建造者模式、 工厂模式 、原型模式。 结构型模式 ： 适配器模式 、桥接模式、 装饰模式 、组合模式、 外观模式 、享元模式、代理模式。 行为型模式 ： 模版方法模式 、 命令模式 、迭代器模式、 观察者模式 、中介者模式、备忘录模式、解释器模式、 状态模式 、 策略模式 、职责链模式(责任链模式)、访问者模式。 Blog Catalogue： 1. 设计模式 观察者模式(Observer Pattern) 以微信公众服务为例 2. 设计模式 工厂模式(Factory Pattern) 从卖肉夹馍说起 3. 设计模式 单例设计模式(Singleton

1、定义 Decorator模式（别名Wrapper）：动态将职责附加到对象上，若要扩展功能，装饰者提供了比继承更具弹性的代替方案。 2、意图： 动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。 3、设计原则： 1. 多用组合，少用继承。 利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态地进行扩展。 2. 类应设计的对扩展开放，对修改关闭。 4、要点： 1． 装饰者和被装饰对象有相同的超类型。 2． 可以用一个或多个装饰者包装一个对象。 3． 装饰者可以在所委托被装饰者的行为之前或之后，加上自己的行为，以达到特定的目的。 4． 对象可以在任何时候被装饰，所以可以在运行时动态的，不限量的用你喜欢的装饰者来装饰对象。 5． 装饰模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配，而不是获得其行为。 6． 装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。在实际项目中可以根据需要为装饰者添加新的行为，做到“半透明”装饰者。 7． 适配器模式的用意是改变对象的接口而不一定改变对象的性能，而装饰模式的用意是保持接口并增加对象的职责。 5、实现图 6、具体实例 装饰模式结构图 Component是定义一个对象接口

装饰（Decorator）模式又名包装（Wrapper）模式[GOF95]。装饰模式以对客户端透明的方 式扩展对象的功能，是继承关系的一个替代方案。 装饰模式类图： 类图说明： 抽象构件（Component）角色：给出一个抽象接口，以 规范准备接收附加责任的对象。 具体构件（Concrete Component）角色：定义一个将 要接收附加责任的类。 装饰（Decorator）角色：持有一个构件（Component） 对象的实例，并定义一个与抽象构件接口一致的接口。 具体装饰（Concrete Decorator）角色：负责给构件对 象"贴上"附加的责任 示例代码： class Program { static void Main(string[] args) { Component component = new ConcreteComponent(); ConcreteDecoratorA decoratorA = new ConcreteDecoratorA(); ConcreteDecoratorB decoratorB = new ConcreteDecoratorB(); decoratorA.SetComponent(component); decoratorB.SetComponent(decoratorA); decoratorB.Operation();

装饰模式 装饰模式，就是可以动态的给一个对象添加一些额外的职责，就增加新功能来说，装饰模式比生成子类的方式更加灵活。其实可以把装饰模式理解为给一个人穿衣服的过程，给人穿衣服，所以首先得需要一个人，其次就得需要衣服了，对应到装饰模式当中，就是首先得需要一个被装饰得主体，接着就是需要装饰了。有可能并不是一个人，所以可以选择性的抽出一个人的接口对象，而衣服不可能是只穿一件衣服，所以就需要一个服装基类，然后就是实现各式各样具体的服装了（如：T恤，裤子，夹克……）接下来就是装饰的过程，首先需要实例化出一个人的对象，然后需要将这个对象设置到服装基类中作为装饰主题，接着给人穿什么衣服，就依个人喜好而定了 _ 。代码实现如下（参考《大话设计模式》）： 装饰过程： 这里，开始觉得用生成子类的方法也可以实现该功能，增加一个功能，在这里就是具体增加一个服装，就多一个服装基类的子类，但是如果这样做，就需要实例化完所有对象之后，一个一个运行show方法，这样本该在内部组装好西，最后只需show一次即可的东西，最后确实在外部组装完成，这样感觉不太好，就像穿衣服一样，不管你今天穿什么衣服，都应该自己起床穿好，最后其他人看到的只是你穿好衣服的样子，而不是你拿着衣服，当着别人面一件一件穿好。 其实，装饰模式通俗来讲，就是有一个主题，然后一层一层往这个主题上“套”东西。 来源： CSDN 作者： virgofarm

面前对象是对现实的映射，而不仅仅是对现实中物体的映射，水果变成苹果是，我们开发员本能的会写父子两个类，没问题，那么有 ABS 的汽车和没有 ABS 的汽车你会写几个类呢？如果再加上国产和进口的区别呢？很快就会产生一堆堆的类，子类复子类，子类何其多 ! 装饰模式的核心在于解决对象操作的具体方法甚至是方法本身的不确定，比如在类中新增一个方法。 为啥叫装饰模式呢？我想是这样的，那天 Gof 在盖房子，房子盖好了， Erich Gamma 说要能使用太阳能、 Richard Helm 说要能看电视、 Ralph Johnson 说给个篮球架吧， John Vlissides 最离谱非要个游泳池，传统理念好像要盖四个房子，而且万一他们看不得别人的好，也要求再加就麻烦了，我们就装饰他，要太阳能的加个太阳热水器，不要的就拿走，反正是你要就加，不要就去，在国外装修和装饰是不是一个词呢，可能是吧。 动机（ Motivation ） 上述描述的问题根源在于我们 “ 过度地使用了继承来扩展对象的功能 ” ，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增 多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀（多继承）。 如何使 “ 对象功能的扩展 ” 能够根据需要来动态地实现？同时避免 “ 扩展功能的增多 ” 带来的子类膨胀问题？从而使得任何 “

对新房进行装修并没有改变房屋用于居住的本质，但它可以让房子变得更漂亮、更温馨、更实用、更能满足居家的需求。 例如一张照片，我们可以不改变照片本身，给它增加一个相框，使得它具有防潮的功能，而且用户可以根据需要给它增加不同类型的相框，甚至可以在一个小相框的外面再套一个大相框。 在软件设计中，我们也有一种类似新房装修的技术可以对已有对象（新房）的功能进行扩展（装修），以获得更加符合用户需求的对象，使得对象具有更加强大的功能。这种技术对应于一种被称之为装饰模式的设计模式 装饰模式注意事项： 　　 (1) 尽量保持装饰类的接口与被装饰类的接口相同，这样，对于客户端而言，无论是装饰之前的对象还是装饰之后的对象都可以一致对待。这也就是说，在可能的情况下，我们应该尽量使用透明装饰模式。 (2) 尽量保持具体构件类 ConcreteComponent是一个“轻”类，也就是说不要把太多的行为放在具体构件类中，我们可以通过装饰类对其进行扩展。 (3) 如果只有一个具体构件类，那么抽象装饰类可以作为该具体构件类的直接子类 主要优点 　　 (1) 对于扩展一个对象的功能，装饰模式比继承更加灵活性，不会导致类的个数急剧增加。 (2) 可以通过一种动态的方式来扩展一个对象的功能，通过配置文件可以在运行时选择不同的具体装饰类，从而实现不同的行为。 (3) 可以对一个对象进行多次装饰

装饰者模式：动态地给一个对象添加一些额外的职责，就增加功能来说，Decorator模式比生成子类更为灵活。 Decorator模式的工作原理是：可以创建始于Decorator对象（负责新的功能的对象）终于原对象的一个对象“链”。 图1装饰者链 装饰者模式隐含的是通过一条条装饰链去实现具体对象，每一条装饰链都始于一个Componet对象，每个装饰者对象后面紧跟着另一个装饰者对象，而对象链终于ConcreteComponet对象。 装饰者模式 ：动态地将责任附加到对象上.若要扩展功能,装饰者提供了比继承更有弹性的替代方案。 装饰者模式 类图: 问题: 说装饰者模式比用继承会更富有弹性,在类图中不是一样用到了继承了吗? 说明: 装饰者和被装饰者之间必须是一样的类型,也就是要有共同的超类。在这里应用继承并不是实现方法的复制,而是实现类型的匹配。因为装饰者和被装饰者是同一个类型,因此装饰者可以取代被装饰者,这样就使被装饰者拥有了装饰者独有的行为。根据装饰者模式的理念,我们可以在任何时候,实现新的装饰者增加新的行为。如果是用继承,每当需要增加新的行为时,就要修改原程序了。 具体案例: 有存储在数据库中的新闻,有存储在XML文件中的新闻(一般都是推荐新闻,内容比较少)。 在没有接触设计模式时,都是针对具体实现编程,读取数据库新闻时直接写一个基于数据库的方法,读取推荐新闻时再写一个基于XML的方法

J ava设计模式之装饰模式 转载请注明出处： http://blog.csdn.net/zhaoyanjun6/article/details/56488020 前言 其实我们可以这样理解装饰器模式， 就拿自己举例子，你把自己裸体的样子，想象成被装饰的对象。你的鞋子，你的寸衣，你的外套，你的手表，你的帽子 等等，都是你的装饰物，你和这些装饰物，是装饰和被装饰的关系。 实例展示 好了，现在我们用代码的方法去理解这样概念。 首先，我们发现，不管是裸体的人，还是你的鞋子、帽子，都有展示的功能，我们称之为show 方法。 我们定义一个接口，它具有展示的功能，也就是show() , package com.user; /** * 定义接口 * @author T * */ public interface AbstractPerson { //具有展示的功能 void show() ; } 现在应该定义一个裸体的自己了，Me 类 package com.user; /** * 定义一个具体的人，就是被装饰者 * @author T * */ public class Me implements AbstractPerson { @Override public void show() { System.out.println( "什么都没穿，我展示的是裸体"); } } 下面该定义，鞋子

文章目录 生成式 生成式小案例 生成器 生成器小案例 生产者-消费者模型 生成器、迭代器与可迭代对象 闭包 装饰器 生成式 列表生成式 ：用来生成列表的特定语法形式的表达式。是Python提供的一种生成列表的简洁形式, 可快速生成一个新的list 普通的语法 格式： [exp for iter_var in iterable] #列表生成式：生成100个1～50之间的随机数值。 #先使用空列表 循环100次 每循环一次在random.randint(1,50)中选一个值保存到[]中 print([random.randint(1,50) for i in range(1,100)]) 执行结果： [42, 8, 22, 16, 34, 8, 37, 39, 31, 30, 7, 3, 11, 17, 39, 4, 8, 8, 16, 5, 12, 27, 15, 35, 1, 9, 5, 17, 41, 9, 14, 22, 29, 16, 30, 30, 44, 40, 32, 30, 20, 2, 28, 35, 19, 21, 38, 35, 12, 42, 30, 35, 9, 35, 34, 25, 44, 6, 8, 26, 26, 13, 19, 15, 37, 40, 15, 44, 1, 16, 27, 38, 15, 44, 5, 39, 23, 25, 7,

装饰者模式 动态地将责任附加到对象上。若要拓展功能，装饰者提供了比继承更有弹性的替代方案。 1. 角色 抽象构件（Component）角色：要包装的原始对象，是一个抽象类或接口。 具体构件（ConcreteComponent）角色：最终要装饰的实际对象，是Component的实现类。 装饰（Decorator）角色：是一个抽象类，继承自Component，同时持有一个对Component实例对象的引用。 具体装饰（ConcreteComponent）角色：具体的装饰者对象，是Decorator的实现类，负责给ConcreteComponent附加责任。 2. Demo背景 一个奶茶店每款奶茶可以自己选添加一些辅料如燕麦，布丁，红豆，珍珠等等。添加辅料不同可能价格也不同，又或者是我们全都要，同时添加多种辅料，这样我们设计对象时就遇到了困难，难道要排列组合去创建子类吗？这样做显然是不好的，类数量爆炸，设计死板。在这时候我们就可以引用装饰者模式，用组合的方式代替继承。 3. 代码实现 抽象构件类（Component）：MilkyTea public abstract class MilkyTea（奶茶） { public string description; public abstract double GetFee(); //与java不一样