装饰模式

发现太过于刻意按照计划来写博客，有点不实际，刚好最近在一个网课上复习AOP的知识，讲到了装饰器模式和代理模式，顺便复习总结一下。 首先了解一下装饰器模式，从名字里面可以看出来，装饰器模式就类似于房子装潢吧，比如刚买的毛坯房，只有一个没有门，直接就可以进去。 首先设计一个房子类Room，实现一个进入方法Access /// <summary> /// 抽象接口 用来进行约束 /// </summary> public interface IAccess { void Access(); } /// <summary> /// 用户类 /// </summary> public class Room: IAccess { /// <summary> /// 进入房子操作 /// </summary> public void Access() { Console.WriteLine("进房子了"); } } 那么现在这个类就拥有了进入房子的功能了，那么后期我们需求变更，这个房子加了一个门，那这样我就需要多一个开门的功能了，但是我又不想改变room这个类，那么需要怎么做呢，这个时候就可以用到装饰器模式了 这里定义一个门Door类，添加开门关门方法 /// <summary> /// 门类 /// </summary> public class Door : IAccess { Room

写在前面 设计模式是基于固定设计场景的一套解决方案，目的是为了完成开闭原则，或者说面向后续的需求变更，以成本最低的改动和测试完成新功能。同时设计模式也是一种程序员之间的交流语言，可以省去很多沟通成本。 在工作的过程中，从最初不知如何使用设计模式，到中间刻意使用设计模式，到今天稍有好转的正确的使用设计模式，踩了许多坑，也有过度设计的时候，为了避免今后在犯同样的错误，所以准备将自己在项目实践的过程中使用过的设计模式记录下来。 设计模式中，有一些实战里用过，有的没用过，没用过的应该是对这个设计方法没有领悟透彻，所以不知道该怎么用。 目前先按照自己的理解记录下来，有更深的领悟会更新。 创建型设计模式 1、工厂方法模式(FactoryMethod) 工厂方法模式的实质是“定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类。工厂方法让类的实例化推迟到子类中进行。” 工厂方法模式，是在抽象类中定义创建对象的方法，调用声明创建过程（抽象方法，但创建对象的过程的实现是在实现类中定义。 也就是说，在创建对象时，创建步骤是固定的，但各个步骤的实现是多种多样的，这种情况下可以使用工厂方法。 例如：创建一个电脑主机，需要安装CPU，内存，硬盘，显卡。这个安装步骤是固定的，但是由不同的工厂实现类去实现这几个步骤。 这种父类声明，子类实现的方式有很多，把这种方法用于创建对象，就叫工厂方法

https://docs.djangoproject.com/en/2.0/topics/class-based-views/ Django中View是一个可调用对象，接受一个request，并且返回一个response。view可以是一个简单的Python函数，但是也可以是一个可转化成view的类。使用类作为view，通过继承与混合，可以帮助你重用你的代码。 class 类型的view VS 函数型的view： 函数型的view：简单明了，易于编写。缺点：场景覆盖率小，难以扩展。且不易统一配置管理。 class类型的view：易于扩展，代码重用，但是可能会比函数型的view稍稍难以上手。 1 使用基于类的view 对于 view class，就是使用类的不同的实例方法来处理不同的http请求（而对于函数型view，在同一个方法中通过不同的代码分支（如if）来处理不同的http请求） 例如，对于函数型view，可能如下： from django.http import HttpResponse def my_view(request): if request.method == 'GET': # <view logic> return HttpResponse('result') 对于class类型view，则代码如下： from django.http import

一、定义 动态的给一个对象增加额外的职责。 二、特点 结构型模式，作为现有类的一个包装。在不想增加很多子类的情况下拓展类。允许向一个现有的对象添加新的功能，同时又不改变其结构。 三、示例代码： public class Person { String name; public Person() { } public Person(String name) { this.name = name; } public void show() { System.out.println(name); } } public class Finery extends Person { protected Person commponet; public void decorate(Person commponet) { this.commponet = commponet; } public void show() { if (commponet != null) { commponet.show(); } } } public class Tshirt extends Finery { @Override public void show() { System.out.println("T恤衫"); super.show(); } } public class Suit extends

20191126：装饰器 装饰器的定义 装饰器是修改其他函数的功能的函数。@符号是装饰器的语法糖，放在函数开始定义的上方，类似于给函数戴了一个帽子，这个帽子我们称之为装饰器。 当一个函数被装饰器装饰了后，我们调用这个函数的时候并不是真正的执行了这个函数而是将这个函数作为参数传递给装饰器。 概括的讲，装饰器的作用就是为已经存在的对象添加额外的功能 函数装饰器 实现不带参数装饰器 先定义一个装饰函数，一般是一个闭包函数。最简单的装饰器闭包函数如下： def mydecorater(func): def inner(*args,**kwargs): print( " 开始执行初始化操作" ) result = func(*args,**kwargs) print( " 开始执行结束清理操作" ) return result return inner 被装饰器装饰的函数写法如下，在fun_need_decorate上方加上@语法糖后接装饰器函数，表示用mydecorater装饰fun_need_decorate函数。 # encoding: utf-8 @mydecorater def fun_need_decorate(variable_a,variable_b): print( "func 里面的函数执行" ) print( "variable_a" ,variable_a)

目录 一、创建型模式 1. 单例模式 1.1请手写一个单例 1.2单例模式的优点和应用？ 1.3单例模式的缺点 2. 工厂类相关模式 2.1工厂模式、简单工厂模式、抽象工厂模式 2.2工厂模式的优点和应用 2.3工厂模式的不足 3、建造者模式 3.2建造者模式的优点和使用场景 3.3建造者模式的缺点 4、原型模式 4.1原型模式 4.2原型模式的优点和使用场景 4.3原型模式的缺点 二、结构类设计模式 1、适配器模式 1.1适配器模式 1.2适配器模式的优点和使用场景 2、桥接模式 2.1桥接模式 2.2桥梁模式的优点和应用场景 3、 装饰器模式 3.1对装饰器的理解 ，并写出一个计时器记录方法执行性能的装饰器？ 3.2装饰器模式的优点和应用场景 3.3装饰器模式的缺点 4、组合模式 4.1组合模式 4.2组合模式的优点和使用场景 4.3组合模式的缺点 5、门面模式 5.1门面模式 5.3门面模式的缺点 6、享元模式 6.1享元模式 6.2享元模式的优点和使用场景 6.3享元模式的缺点 7、代理模式 7.1代理模式 7.2代理模式的优点和使用场景 7.3代理模式的缺点 三、行为类设计模式 1、策略模式 1.1策略模式 1.2策略模式的优点和应用场景 1.3策略模式的缺点 2、责任链模式 2.1责任链模式 2.2责任链模式的优点和应用场景 2.3责任链模式的缺点 3、 命令模式 3

装饰器模式 这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。 1、创建一个抽象类 1 public interface Shape { 2 void draw(); 3 } Shape 2、编写抽象类的实现类 1 public class Circle implements Shape { 2 @Override 3 public void draw() { 4 System.out.println("Circle"); 5 } 6 } Circle 1 public class Rectangle implements Shape { 2 @Override 3 public void draw() { 4 System.out.println("Rectangle"); 5 } 6 } Rectangle 3、创建实现了 Shape 接口的抽象装饰类 1 public abstract class ShapeDecorator implements Shape{ 2 protected Shape decoratedShape; 3 4 public ShapeDecorator (Shape decoratedShape){ 5 this.decoratedShape = decoratedShape; 6 } 7 8

　　装饰器模式是JAVA开发过程中常用的一种设计模式，该设计模式用于对类进行横向的功能扩展，也就是达到对类进行“装饰”的目的。 　　装饰器模式的类图一般如下： 　　 　　以实体类基类的引用为入参，装饰类可以装饰整个继承链上的实体类。 　　很多刚刚接触装饰模式的开发者可能会认为，为一个类增加一个装饰类多此一举，使用继承也可以对类的功能进行扩展。 　　但其实装饰模式的核心在于“装饰”，它是一种横向的扩展，并不影响原来类的核心功能和定位。另外通过向上转型传入参数，装饰类可以使用同一个引用并装饰一条继承链中的所有类，具有很好的通用性和可读性。 　　比如有如下场景，我们有一条继承链： 　　 　　代码如下： 　　货车省略。。。 　　公交车、出租车、货车都是汽车的子类，它们同时拥有 run() 方法且都有自己的实现（都重写了父类的run()方法）。如果我们在后期考虑到，碰到大雾情况，汽车在行驶之前需要开启雾灯。如果不使用装饰模式，我们必须在每个子类的run()方法中加上“开启雾灯”，这样做显然会产生很多重复代码，不够优雅。 　　现在我们来定义一个装饰器CarDecorator如下： 　　将一个Car的实例传入装饰器，并执行car的run方法。该类只是一个声明，后续所有的装饰器都会集成自该类。因为我们并不一定只需要开启雾灯的装饰类，我们可能还需要下雨天开启雨刷的装饰类。装饰类应当有自己的继承链

装饰器形成的过程 : 最简单的装饰器 有返回值的 有一个参数 万能参数 装饰器的作用 原则 ：开放封闭原则 语法糖 ：@ 装饰器的固定模式 import time print(time.time()) # 获取当前时间 time.sleep(10) #让程序在执行到这个位置的时候停一会儿 def timmer(f): #装饰器函数 def inner(): start = time.time() ret = f() #被装饰的函数 end = time.time() print(end - start) return ret return inner @timmer #语法糖 @装饰器函数名 def func(): #被装饰的函数 time.sleep(0.01) print('老板好同事好大家好') return '新年好' # func = timmer(func) ret = func() #inner() print(ret) 装饰器的作用 —— 不想修改函数的调用方式 但是还想在原来的函数前后添加功能 timmer就是一个装饰器函数，只是对一个函数 有一些装饰作用 原则： 开放封闭原则 开放 ： 对扩展是开放的 封闭 ： 对修改是封闭的 封版 def outer(): def inner(): return 'inner' inner() outer()

学习开源框架源码，除了储备点知识以便于与面试官互相忽略之外，我想最重要的还是去学习大神如何写代码，如何做到职责单一，如何做到可扩展等。。。 本篇，试着总结一下mybatis在缓存模块使用到的装饰模式。 或许一说到装饰模式就会扯到装饰模式四种角色，但我觉得这些都是扯蛋，没必需照本宣科，我觉得myabtis框架也不是完全的装饰模式，或许可以说是变异版本。 其实，我觉得大多的设计模式无非就是面向接口编程与接口引用的组合罢了！ 下面看看mybatis框架的cache模块是如何使用装饰模式的 1. 首先，定义了一个cache接口，具体的功能都在接口中说明了，主要是putObject 和getObject public interface Cache { String getId(); void putObject(Object key, Object value); Object getObject(Object key); Object removeObject(Object key); void clear(); int getSize(); default ReadWriteLock getReadWriteLock() { return null; } } 2. 然后，再看一下Cache的继承体系 清一色的java类，并没有啥抽象类或者接口，这就与教科书中的装饰模式有点区别了。。。。