装饰模式

职责：动态的为一个对象增加新的功能 　　　装饰器模式是一种用于代替继承的技术，无需通过继承增加子类就能扩展对象的新功能。使用对象的关联关系代替继承关系，更加灵活，同时避免类型体系的快速膨胀。 实现细节： ——Component抽象构件角色：真实对象和装饰对象有相同的接口。这样，客户端对象就能够以与真实对象相同的方式同装饰对象交互。 ——ConcreteComponent具体构件角色（真实对象）：io流中的FileInputStream、　　　　FileOutputStream ——Decorator装饰角色：持有一个抽象构件的引用。装饰对象接受所有客户端的请求，并把这些请求转发给真实的对象。这样，就能在真实对象调用前后增加新的功能。 ——ConcreteDecorator具体装饰角色：负责给构件对象增加新的责任。 开发中的使用场景： 　　IO中输入流和输出流的设计 　　Swing包中图形界面构件功能 　　Servlet API中提供了一个request对象的Decorator设计模式的默认实现类HttpServletRequestWrapper，HttpServletRequestWrapper类增强了request对象的功能。 　　Struts2中，request，response，session对象的处理 1. 创建一个抽象组件ICar接口

Java程序员们应该对java.io对不会陌生，因为java.io包采用了装饰器模式。 一、定义： Decorator装饰器，顾名思义，就是动态地给一个对象添加一些额外的职责，就好比为房子进行装修一样。因此，装饰器模式具有如下的特征： 它必须具有一个装饰的对象。 它必须拥有与被装饰对象相同的接口。 它可以给被装饰对象添加额外的功能。 用一句话总结就是：保持接口，增强性能。 装饰器通过包装一个装饰对象来扩展其功能，而又不改变其接口，这实际上是基于对象的适配器模式的一种变种。它与对象的适配器模式的异同点如下。 相同点：都拥有一个目标对象。 不同点：适配器模式需要实现另外一个接口，而装饰器模式必须实现该对象的接口。 二、 典型的装饰器模式的图： 三、相关实例： 1、 Sourcable接口定义了一个方法 operation() 。 Java代码 package pattern.decorator; public interface Sourcable { public void operation(); } 2、 Source.java 是 Sourcable.java 的一个实现， operation() 方法的实现就是简单的负责往控制台输出一个字符串： Java代码 package pattern.decorator; public class Source implements

介绍： 在软件系统中，我们有时候需要对对象的功能进行扩展，继承虽然能够解决此类问题，但是由于继承本身的一些缺点使得扩展不能动态的进行，并且面对功能扩展间的组合，使用继承会使得子类急剧膨胀。装饰模式正是用来解决这类问题的，对对象功能进行任意的扩展而不用担心类继承所带来的膨胀。 现实中的例子： “疯狂坦克”，我想大家都玩过吧，每一关中都会随机爆出一些可吃的东西，譬如防护罩：坦克吃了，增强抗打能力；譬如子弹：坦克吃了，发射子弹的速度快了;譬如石墙：坦克吃了可以打碎石墙…… 解决方案： 如果叫我实现这些功能（防护罩：坦克吃了，增强抗打能力；譬如子弹：坦克吃了，发射子弹的速度快了;譬如石墙：坦克吃了可以打碎石墙），我该如何实现呢？ 方案一： 思路：很显然，不管坦克吃了什么东西变成什么东西，它最终还是一个坦克。只不过根据所吃东西的不同发射子弹后产生的效果不同而已。那么继承无疑是很好的选择。 类图： 代码片段 public abstract class Itank { public int HP; public string Name; public Itank(string name) { this.Name = name; } public abstract void Shot(Itank destination); public virtual void BeAttacked(int hp

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。 常用应用场景： 工厂模式 ：IOC就是典型的工厂模式 代理模式 ：AOP就是代理实现的 Facade模式 ：shiro框架的核心 单例模式 Spring默认就是单例 不变模式 string 八大基本数据类型都是单例 Future 模式 异步调用。即请求时只拿到一个契约，约定以后可以获取这个东西 来源： https://www.cnblogs.com/duguangming/p/11407721.html

##返回函数 高阶函数除了可以接受函数作为参数外，还可以把函数作为结果值返回 def cacl_sum(*args): all_sum = 0 for i in args: all_sum += i return all_sum cacl_sum( 1 , 2 , 3 , 4 ) 但是,如果不需要立刻求和,而是在后面的代码中,根据需要不返回求和的结果,而是返回求和的函数：如果 不需要立刻求和，而是在后面的代码中根据需要不返回求和的结果，而是返回求和的函数。如下： 在函 数lazy_sum中又定义了函数cacl_ sum,并且内部函数cacl_sum可以引用外部函数lazy_sum 的 参数和局部变量,当 lazy_sum 返回函数cacl_sum时,相关参数和变量都保存在返回的函数中,这 种函数形式称为“闭包(Closure)” def lazy_sum(*args): def cacl_sum (): all_sum = 0 for i in args: all_sum += i return all_sum return cacl_sum f = lazy_sum( 1 , 2 , 3 , 4 ) #调用 lazy_sum() 时,返回的并不是求和结果,而是求和函数 f () #调用函数 f 时,才真正计算求和的结果 请再注意一点,当我们调用 lazy_sum() 时

1、装饰者模式与代理模式 (静态代理)　 　 在日常开发里面，我们经常需要给某个类的方法增加加某些特定的功能。 例如：有婴儿，婴儿会吃饭和走动，如以下类 1 package com.scl.designpattern.proxy; 2 3 //婴儿类 4 public class Child implements Human 5 { 6 public void eat() 7 { 8 System.out.println("eat something...."); 9 } 10 11 @Override 12 public void run() 13 { 14 System.out.println("Child run very slow"); 15 } 16 } 婴儿类 　　 突然有一天，家长发现不行，孩子不能随便吃东西，而且吃饭前一定要洗手。但是孩子太小(被委托方)，不会自己洗手。家长(Client 端)又没法照顾孩子。那简单，找个保姆照顾孩子！ 让保姆类和婴儿类共同实现同一个接口，让保姆类全程管理小孩，同时在家长眼里，只要看到保姆在帮孩子洗手就可以了。于是，有以下内容。 1 package com.scl.designpattern.proxy; 2 3 //保姆类 4 public class BabySitter implements Human 5 { 6 7

关于我 一个有思想的程序猿，终身学习实践者，目前在一个创业团队任team lead，技术栈涉及Android、Python、Java和Go，这个也是我们团队的主要技术栈。 Github：https://github.com/hylinux1024 微信公众号：终身开发者(angrycode) 谈谈装饰器(Decorator)的实现原理 熟悉 Java 编程的程序猿对 装饰器模式 一定不陌生，它是能够动态的给一个类添加新的行为的一种设计模式。相对于通过继承的方式使用装饰器会更加灵活。 在 Python 里面装饰器( Decorator )也是一个非常重要的概念。跟装饰器模式类似，它 能够动态为一个函数、方法或者类添加新的行为 ，而不需要通过子类继承或直接修改函数的代码来获取新的行为能力，使用 Decorator 的方式会更加 Pythonic 。 要理解 装饰器 我们就要从函数说起。 0x00 函数 在 Python 中函数是作为一级对象存在的（一切都是对象），它拥有自己的属性，函数名可以赋值给一个变量，也可以作为另一个函数的参数进行传递。 1、定义函数 def fib(n): """打印小于 n 的 fibonacci 数列""" a, b = 0, 1 while a < n: print(a, end=' ') a, b = b, a + b print() def call

装饰者模式 动态地将责任附加到对象上。若要拓展功能，装饰者提供了比继承更有弹性的替代方案。 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不一样

Decorator装饰器，顾名思义，就是动态地给一个对象添加一些额外的职责，就好比为房子进行装修一样。因此，装饰器模式具有如下的特征： 它必须具有一个装饰的对象。 它必须拥有与被装饰对象相同的接口。 它可以给被装饰对象添加额外的功能。 用一句话总结就是：保持接口，增强性能。 装饰器通过包装一个装饰对象来扩展其功能，而又不改变其接口，这实际上是基于对象的适配器模式的一种变种。它与对象的适配器模式的异同点如下。 相同点：都拥有一个目标对象。 不同点：适配器模式需要实现另外一个接口，而装饰器模式必须实现该对象的接口。 先写一个接口类：Sourcable package model; public interface Sourcable { public void opration(); } 再设置一个实现类：Source，重写方法。 package model; public class Source implements Sourcable{ public void opration(){ System.out.println("原始类方法"); } } 装饰器类 Decorator1.java 采用了典型的对象适配器模式，它首先拥有一个 Sourcable 对象 source ，该对象通过构造函 数进行初始化。然后它实现了 Sourcable.java 接口，以期保持与 source

一、设计原则 封装变化 多用组合，少用继承 针对接口编程，不针对实现编程 为交互对象之间的松紧耦合设计而努力 对扩展开放，都修稿关闭 依赖抽象，不要依赖具体类 最少知识原则：之和朋友交谈 好莱坞原则：别找我，我会找你（由超类主控一切，当他们需要的时候，自然回去调用子类） 类应该只有一个改变的理由 二、设计模式 策略模式 定义算法族，分别封装起来，让他们之间可以互相替换，次模式让算法的变化独立于使用算法的客户 2. 观察者模式 在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新 3. 装饰者模式 动态的将责任附加到对象上。想哟啊扩展功能，装饰者提供有别于继承的另一种选择 要点： 继承属于扩展形式之一，但不见得是达到弹性设计的最佳方式 在我们的设计中，应该允许行为可以被扩展，而无需修改现有的代码 组合和委托可用于在运行时动态地加上新的行为 除了继承，装饰者模式也可以让我们扩展行为 装饰者模式意味着一群装饰者类，这些类用来包装具体组件 装饰者类反应出被装饰者的组件类型（事实上，他们具有相同的类型，都是经过接口或继承实现） 装饰者可以被装饰者的行为前面与/或后面加上自己的行为，甚至将被装饰者的行为整个取代掉，而达到特定的目的 可以用无数个装饰者包装一个组件 装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型