装饰模式

第一、设计模式之间的关联关系和对比 1.1单例模式和工厂模式 实际业务代码中，通常会把工厂类设计为单例。 1.2策略模式和工厂模式 1.工厂模式包含工厂方法模式和抽象工厂模式是创建型模式，策略模式属于行为型模式。 2.工厂模式主要目的是封装好创建逻辑，策略模式接收工厂创建好的对象，从而实现不同的行为。 1.3策略模式和委派模式 1、策略模式是委派模式内部的一种实现形式，策略模式关注的结果是否能相互替代。 2、委派模式更关注分发和调度的过程。 模板方法模式和工厂方法模式工厂方法是模板方法的一种特殊实现。 工厂方法模式 模板方法模式 对于工厂方法模式的 create()方法而言，相当于只有一个步骤的模板方法模式。这一个步骤交给子类去实现。而模板方法呢， 将 needHomework()方法和 checkHomework()方法交给子类实现，needHomework()方法和 checkHomework()方法又属于父类的某一个步骤且不可变更。 1.4模板方法和策略模式 1、模板方法和策略模式都有封装算法。 2、策略模式是使不同算法可以相互替换，且不影响客户端应用层的使用。 3、模板方法是针对定义一个算法的流程，将一些有细微差异的部分交给子类实现。 4、模板方法模式不能改变算法流程，策略模式可以改变算法流程且可替换。策略模式通常用来代替 if...else...等条件分支语句。 策略模式

目录 Flask基础 内容详细 配置文件 路由系统 视图 请求相关的数据 响应 示例程序一 html页面 安全登录版本一 知识点 装饰器适用--版本二 版本三****实现权限管理 模板的渲染 模板后端的书写 session 闪现 中间件 特殊的装饰器**** Flask基础 对于一个web框架而言，一定要有的就是路由，视图，模板语法 对于一个没有见到的框架，从路由入口，然后走视图 1.谈谈你对django和flask的认识？ 1.django是一个大而全的框架，内置了很多的组件，比如分页，缓存，orm... 2.flask轻量级的，可扩展性强，可定制性强 3.两个框架你选择哪个？因人而异 2.flask和django最大的不同点： 1.request/session（django中的session是依附在request对象中传递进来的，但是flask是导入的） 3.flask知识点 - 可以设置静态文件和模板（实例化flask对象的时候配置的...） - 路由装饰器，对象点route @app.route('/index',methods=['GET','POST']) - 请求相关的 request.form request.args request.method - 响应 render redirect -session # 放值 session['xx'] = 123 #

第一章 策略模式 00设计原则： 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码放在一起。 把会变化的部分取出并封装起来，好让其它部分不会受到影响。结果如何？代码变化引起的不经意后果变少，系统变得更有弹性。 00设计原则： 针对接口编程，而不是针对实现编程。 “针对接口编程”真正的意思是“针对超类型编程”： 这里的接口有多个含义，接口是一个概念，也是一种java的interface构造。”针对接口编程“关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际情况执行到真正的行为，不会被绑死在超类型的行为上。这句话可以更明确的说成”变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口。如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着声明类时不用理会以后执行的真正对象类型。 OO设计原则： 多用组合，少用继承 使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以“在运行时动态地改变行为”，只要组合的行为对象符合正确的接口标准即可。 策略模式 定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 类图 JDK java.util.Comparator#compare() javax.servlet.http.HttpServlet javax.servlet

你有一座房子，你要装修你的房子 对已有对象增加新功能，而不改变该对象。 package structural.pratice; public class Decoretor2PMain { public static void main(String[] args) { House f = new FirstHouse(); DecoretationWorker worker = new DecoretationWorker(f); worker.wholeHouse(); } } //房子设计图 interface House{ void beWall(); void beWindows(); void beDoors(); void beRoof(); void beFloor(); void wholeHouse(); } //建造房子 class FirstHouse implements House{ @Override public void beWall() { System.out.println("建好了墙！"); } @Override public void beWindows() { System.out.println("建好了窗户！"); } @Override public void beDoors() { System.out.println(

将某一结果通过HTML发布，首先将内容转化为一个HTML文本，然后增加HTTP头 /** * 核心组件 * 装饰接口，用于处理具体的内容 */ public interface IPacketCreator { public String handleContent(); } /** * 具体的内容，构造要发布信息的核心内容 */ public class PacketBodyCreator implements IPacketCreator { @Override public String handleContent() { return "Content of Packet"; } } /** * 维护核心组件component，核心业务逻辑委托component完成 */ public abstract class PacketDecorator implements IPacketCreator{ IPacketCreator component; public PacketDecorator(IPacketCreator c) { component = c; } } /** * 负责将给定的内容转化为html内容 */ public class PacketHTMLHeaderCreator extends PacketDecorator{ public

JVM:”上次给我招的工人不错啊！” oo程序员:”………..” JVM:”现在来我开的博物馆生意越来越好了，原来”舞台剧”的方式已经不能满足顾客的需求了” oo程序员:”………..” JVM:”我决定要换一种运营模式，把每个演播厅都租出去，让那些想表演节目的对象们来租演播厅和相关器械，这样我就能坐地收钱了！” oo程序员:”………..” JVM:”合伙干吧？怎么样？你三我七！” oo程序员:”………..” JVM:”四六？” oo程序员:”成交！先说说需求。” JVM:”首先有不同类型的演播厅和不同的装饰品/器械，每种物品都要付一定的租金，你要做的就是一件事，把总租金（演播厅+饰品/器械）算出来。” oo程序员:”把价格表给我！” 仔细一想也对，无论是演播厅还是装饰品，都需要描述（description）和cost（价格），写一个共同的父类无可厚非。 接着写下你设计的第一个类： 第二个： 第三个： 。。。。。 没有第三个了！这样写下去可是无穷无尽的！没办法，换个思路。 在演播厅里，无论什么装饰品都有可能出现，可以把演播厅+饰品看成一个整体，通过饰品相应的has和set来控制饰品，这样的话，设计出来的类如下： 这个看起来好多了，不用写大爆炸数量的类，虽然类写起来又臭（无数的has/set）又长（的确很长）。。。。。 但是有没有更好的方案？ 答案当然是有的，不过我们必须先明确一下

一，首先理解装饰器模式：动态的给一个对象增加一些额外的职责，这是在软件设计原则上面，一个功能装饰另一个功能，每个功能遵循同一个接口是这个模式的特征。 二，定义对象接口和装饰抽象类 1 type IDecorate interface { 2 Do() 3 } 4 5 // 装饰器。实现接口，又定义了自己的事件DecorateFun，相当于抽象类 6 type Decorate struct { 7 // 待装饰的抽象类 8 decorate IDecorate 9 } 10 11 func (c *Decorate) DecorateFun(i IDecorate) { 12 c.decorate = i 13 } 14 15 func (c *Decorate) Do() { 16 if c.decorate != nil { 17 c.decorate.Do() 18 } 19 } 三，具体的装饰类 1 // 具体A装饰 2 type DecorateA struct { 3 Base Decorate 4 } 5 6 // 重写方法，隐式实现接口 7 func (c *DecorateA) Do() { 8 fmt.Printf("执行A装饰") 9 c.Base.Do() 10 } 11 12 // 具体B装饰 13 type DecorateB struct { 14

绪论 其实很早以前就看过一些关于设计模式的文章，知道这个很重要，为此还写了一些demo，但是在实际开发过程中基本没有使用过。原因：不习惯，不记得，其实更多的是不明白什么情况下可以使用。所以导致自己的代码又臭又长，还会重复的造一些轮子，使代码看起来毫无亮点。 这次学习设计模式，更多的是分析理解，思考以往编程中哪些地方可以用到这些模式，从而可以使以后的自己在开发相同模块时可以使用。 理解 结构型模式。 基本概念：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。 现有类的一个包装类，在保证原有的前提下，提供额外的功能。 优点：可独立发展，不会相互耦合。若有多个被装饰类，想扩展同样功能，可使用一个装饰类，提高开发效率。 缺点：多层装饰比较复杂。 代码 AudiCar.java public class AudiCar implements Car { @Override public void carName ( ) { System . out . println ( "车辆名称：奥迪" ) ; } } BlackDecorator.java public class BlackDecorator extends Decorator { public BlackDecorator ( Car car ) { super ( car ) ; }

目录 一、创建型模式 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

概念： 在装饰模式中的角色有： 　　●　　 抽象构件(Component)角色： 给出一个抽象接口，以规范准备接收附加责任的对象。 Person TokenStream 　　●　　 具体构件(ConcreteComponent)角色： 定义一个将要接收附加责任的类,实际中需要附加的类 CodingFarmer StandardTokenizer 　　●　　 装饰(Decorator)角色： 持有一个构件(Component)对象的实例，并定义一个与抽象构件接口一致的接口。 Everyman TokenFilter 　　●　　 具体装饰( Concrete Decorator)角色： 负责给构件对象“贴上”附加的责任。它都有具体构件角色的一个对象引用 AnalysisDesigner SpecialCharFilter 运行测试类的结果： 需求分析!界面设计!码农难道每天只是加班敲代码,难道就没有其他的事情做了吗？,错了,看看我的上面和下面,还有很多没写与客户沟通,哪些地方还需要修改! 示例： Person类 package designMode.decorator; /** * @Package designMode.decorator * @ClassName: Person * @Description: TODO(人：接口或抽象类 ) 抽象构件角色 * @author