装饰模式

装饰模式有点类似于责任链,但是还是有区别,直接上代码 然后运行下 自己体会, 这是文件构成 总计 5个 外加一个 运行实体类 Factory 一 AbstractDecorator 类 public class AbstractDecorator extends GatewayComponent { private GatewayComponent gatewayComponent; public AbstractDecorator(GatewayComponent gatewayComponent) { this.gatewayComponent = gatewayComponent; } 二 BasicComponentGateway 类 public class BasicComponentGateway extends GatewayComponent { @Override public void service() { System.out.println("第一步>>> 网关中获取基本操作...实现"); } } @Override public void service() { if (null != gatewayComponent) gatewayComponent.service(); } } 三 GatewayComponent 类 public

java中装饰者模式 package com . company01 . Decorator ; public abstract class Reader { public abstract void close ( ) ; } package com . company01 . Decorator ; /* 需求：对FileReader类中close()方法进行扩展，并且不能改变FileReader 1.使用继承（但是关联性太强了，代码耦合度太高，不利于项目的扩展。）-->可以理解为 父子关系 2.这里介绍一种方法：装饰者模式。-->可以理解为朋友之间的关系 */ public class FileReader extends Reader { public void close ( ) { System . out . println ( "FileReader closed!" ) ; } } package com . company01 . Decorator ; /* 使用BufferedReader对FileReader中的close方法进行扩展 1.装饰者模式中要求：装饰者中含有被装饰者的引用 2.装饰者模式中要求：装饰者和被装饰者应该实现同一个接口或者类型。 */ public class BufferedReader extends Reader { //

早上，我去鸡蛋饼小摊拿买了一块鸡蛋饼，加了两煎蛋，加了火腿肠，加了生菜，还加了根油条。 吃的好饱。。。 人与动物区别在于，人不仅会吃，而且会思考。所以，这种场景，作为程序员，你应该怎么设计？ 好说！ /** * 反面教材1（BOOM!类爆炸） */ class 鸡蛋饼{ public double cost() { return 3; } } class 鸡蛋饼With鸡蛋 extends 鸡蛋饼{ public double cost() { return super.cost() + 0.5; } } class 鸡蛋饼With火腿 extends 鸡蛋饼{ public double cost() { return super.cost() + 1; } } /** * 反面教材2(违反开闭原则：类应该对扩展开放，对修改关闭) * 以后鸡蛋价格变了，或者加两个鸡蛋，或者再加一种别的调料，想一下你怎么设计？ */ class 鸡蛋饼2{ /** *有鸡蛋 */ private boolean hasEgg; /** *有火腿 */ private boolean hasHuotui; public double cost() { double basecost =3; if(hasEgg) { basecost +=0.5; } if(hasHuotui) { basecost

案例分析之前我先介绍一下常用的结构型设计模式有哪些，然后再根据老师的教学，从其中选择一个进行案例分析： 1 结构型模式简介： 结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。 由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种： 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

Python高级语法——函数式编程——学习心得笔记 1. 函数式编程（FunctionalProgramming) 1.1. 基于lambda演算的一种编程方式 程序中只有函数 函数可以作为参数，同样可以作为返回值 纯函数式编程语言：LISP, Haskell Python函数式编程只是借鉴函数式编程的一些特点，可以理解为一半函数式一半Python 常用函数 高阶函数 返回函数 匿名函数 装饰器 偏函数 lambda表达式 函数：最大程度复用代码 存在问题： 如果函数很小很短，则会造成啰嗦 如果函数被调用次数少，则会造成浪费 对于阅读者来说，造成阅读流程的被迫中断 看实例 小函数 lambda表达式（匿名函数） 一个表达式，函数体相对简单 不是一个代码块，仅仅是一个表达式 可以有参数，有多个参数也可以，用逗号隔开 看实例 1.2. 高阶函数 把函数作为参数使用的函数，叫高阶函数 看实例 系统高阶函数 map: 映射 即把集合或者列表中的元素，每一个元素都按照一定的规则进行操作，生成一个新的 列表或者集合 map函数是系统提供的具有映射功能的高阶函数，返回值是一个迭代对象 看实例 reduce: 归并，缩减 把一个可迭代的对象最后归并成一个结果 对于函数参数有要求： 必须有两个参数，必须有返回结果 = 看实例 filter: 过滤函数 对一组数据进行过滤

一直想写一篇介绍设计模式的文章，让读者可以很快看完，而且一看就懂，看懂就会用，同时不会将各个模式搞混。自认为本文还是写得不错的😂😂😂，花了不少心思来写这文章和做图，力求让读者真的能看着简单同时有所收获。 设计模式是对大家实际工作中写的各种代码进行高层次抽象的总结，其中最出名的当属 Gang of Four ( GoF ) 的分类了，他们将设计模式分类为 23 种经典的模式，根据用途我们又可以分为三大类，分别为创建型模式、结构型模式和行为型模式。 有一些重要的设计原则在开篇和大家分享下，这些原则将贯通全文： 面向接口编程，而不是面向实现。这个很重要，也是优雅的、可扩展的代码的第一步，这就不需要多说了吧。 职责单一原则。每个类都应该只有一个单一的功能，并且该功能应该由这个类完全封装起来。 对修改关闭，对扩展开放。对修改关闭是说，我们辛辛苦苦加班写出来的代码，该实现的功能和该修复的 bug 都完成了，别人可不能说改就改；对扩展开放就比较好理解了，也就是说在我们写好的代码基础上，很容易实现扩展。 创建型模式比较简单，但是会比较没有意思，结构型和行为型比较有意思。 创建型模式 创建型模式的作用就是创建对象，说到创建一个对象，最熟悉的就是 new 一个对象，然后 set 相关属性。但是，在很多场景下，我们需要给客户端提供更加友好的创建对象的方式，尤其是那种我们定义了类

目的 动态的给一个对象添加一些额外的职责。它使用客户端透明的方式来扩展对象功能，并且该模式要比继承更为灵活。 适用范围 以动态透明的方式来给单个对象添加职责。 处理可以撤销的职责。 不能采用生成子类的情况进行扩充。其一是有大量的扩展，为了支持每种组合需要产生大量的子类，使子类数目呈现爆炸性增长。其二是类的定义被隐藏或者不能用来生成子类。 涉及组件 抽象组件：定义一个抽象的接口，规范准备附加的类。 具体组件：将要被附加功能的类，它实现抽象的接口。 抽象装饰者：持有对具体构建角色的引用并且定义与抽象构建角色一致的接口。 具体装饰：实现抽象装饰者角色，负责对具体构建添加额外功能。 类图 代码 Component public interface Person{ void say(); } ConcreteComponent public class Man implements Person{ public void say(){ System.out.println("hello,"); } } Decorator public abstract class Decorator implements Person{ protected Person person; public void setPerson(Person person){ this.person = person; }

前言 在前面的分享中，我们聊了Python独特的以鸭子类型为核心的面向对象风格，并通过《流畅的Python》中提供的两个经典示例，介绍了Python中的序列和分片的实现逻辑，并从中抽象出Python是如何实现接口和多态的，从而开启了我们的Python学习之路。 延续之前的风格，本系列不作为一种Python“从入门到精通”式速成教程，而是作为对Python底层设计逻辑和一些核心编程思想作探讨的分享式博客系列。 今天，我们来探讨Python第二个与传统编译型语言有重大区别的特性——作为一等公民的函数。如果你曾今也是Java的疯狂推崇者，那么，当你看到Python的这一特性时，也会为这种新奇的使用方案感到兴奋，从而进一步的赞叹：Python作为解释性语言，真的把灵活性发挥到了极致。在过去你无法想象，在命令行里，你可以临时定义一个函数，并把该函数赋值给一个对象，从而动态的实现了对象的行为替换。 而这种令人赞叹的灵活性带来的第一个直观的改变就是：过去面向类定义的设计模式可以简化了，使用过Python的朋友一定会不假思索的联想到装饰器模式。过去在Java中实现装饰器模式需要进行复杂的类定义，而真正进行“装饰”的可能只是类中的一个方法而已，但是不得不使用大量的样板代码。另一方面，装饰类的使用需要加载大量的父类，从而也导致了装饰器的使用会损耗不小的性能。今天所介绍的基于Python的装饰器实现

　　1、初识装饰器模式 　　　　装饰器模式，顾名思义，就是对已经存在的某些类进行装饰，以此来扩展一些功能。其结构图如下： 　　　　　　 Component为统一接口，也是装饰类和被装饰类的基本类型。 ConcreteComponent为具体实现类，也是被装饰类，他本身是个具有一些功能的完整的类。 Decorator是装饰类，实现了Component接口的同时还在内部维护了一个ConcreteComponent的实例，并可以通过构造函数初始化。而Decorator本身，通常采用默认实现，他的存在仅仅是一个声明：我要生产出一些用于装饰的子类了。而其子类才是赋有具体装饰效果的装饰产品类。 ConcreteDecorator是具体的装饰产品类，每一种装饰产品都具有特定的装饰效果。可以通过构造器声明装饰哪种类型的ConcreteComponent，从而对其进行装饰。 　　2、最简单的代码实现装饰器模式 //基础接口 public interface Component { public void biu(); } //具体实现类 public class ConcretComponent implements Component { public void biu() { System.out.println("biubiubiu"); } } //装饰类 public class

装饰者模式 动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性， 装饰者模式也体现了 开闭原则(ocp) 示例1 抽象食物 public abstract class Food { /** * 添加调料方法 */ abstract void add(); } 具体食物(面条) public class Noodle extends Food { @Override void add() { System.out.println("面条加面.."); } } 修饰类 public class Decorator extends Food { private Food food; public Decorator(Food food) { this.food = food; } @Override void add() { food.add(); } } 加盐 public class SaltDecorator extends Decorator { public SaltDecorator(Food food) { super(food); } @Override void add() { super.add(); System.out.println("面条加盐..."); } } 加醋 public class VinegarDecorator extends