装饰模式

模拟穿衣服场景 我们来看下面一个具体的案例：每个人一天起床之后都要穿衣服（来装饰自己），这是必不可少的，这样问题就来了，穿什么？按照什么顺序穿？ 如何用程序方便的模拟这个场景的，代码如下： /** * 程序模拟一个人穿衣服的过程 * @author: qhyuan1992 */ // 抽象接口，用来规范将要被附加一些操作的对象 interface People{ public void wear(); } // 具体的对象，该对象将被附加一些额外的操作 class Jane implements People{ public void wear() { System.out.println("今天该穿什么呢?"); } } // 装饰者类，持有一个将要被装饰的接口对象的实例 class Decorator implements People{ private People people; public Decorator(People people) { this.people = people; } public void wear() { people.wear(); } } // 具体的装饰者类，负责给增加附加的操作：穿衬衫 class DecoratorShirt extends Decorator{ public DecoratorShirt(People people)

参考博客: https://www.cnblogs.com/doucheyard/p/5737366.html https://www.cnblogs.com/zhengbin/p/5618564.html 参考以上博客作出的小总结 写完下面的内容之后的总结 : 要区分装饰模式和代理模式, 不能只从代码结构上区分, 而更要从两个模式的 使用目的 和 使用方式 区分 比如装饰器模式的目的, 是为了增强代码 , 为了让装饰之前的类具有更多的功能. 在使用方式上, 装饰器可以一层一层叠加使用 而代理模式 是为了控制对被代理的对象的访问的同时能使用其功能, 使用方式上, 使用者是看不到被代理的对象的 一. 装饰模式 装饰模式没有被装饰类的控制权, 装饰类只是将被装饰类的功能拓展, 两个类都实现同一接口, 也就是装饰类可以装饰实现了这一接口的任何其他类 装饰器模式的特点就是, 我们常常将被装饰类作为参数传递进装饰器中, 如IO流的各种装饰器类 这里我们举个栗子: (1) 首先实现一个女孩接口, 她有一个特点就是漂亮 public interface Girl { void beauty(); } (2)然后你的女朋友实现了这个接口, 而且你女票长得很漂亮 public class GirlFriend implements Girl { @Override public void

Table of Contents 1 引言 2 常见的代理 3 代理模式UML图 4 代理模式实例 5 java动态代理 5.1 java动态代理UML图 6 代理模式与装饰者模式的区别 6.1 装饰者模式UML图 6.2 形象说明 1 引言 我们书写执行一个功能的函数时，经常需要在其中写入与功能不是直接相关但很有必要的代 码，如日志记录，信息发送，安全和事务支持等，这些枝节性代码虽然是必要的，但它会带 来以下麻烦： 枝节性代码游离在功能性代码之外，它下是函数的目的，这是对OO是一种破坏 枝节性代码会造成功能性代码对其它类的依赖，加深类之间的耦合，而这是OO系统所竭 力避免的 枝节性代码带来的耦合度会造成功能性代码移植困难，可重用性降低 从法理上说，枝节性代码应该`监视'着功能性代码，然后采取行动，而不是功能性代码 `通知'枝节性代码采取行动，这好比吟游诗人应该是主动记录骑士的功绩而不是骑士主 动要求诗人记录自己的功绩 2 常见的代理 毫无疑问，枝节性代码和功能性代码需要分开来才能降低耦合程度，符合现代OO系统的要 求，我们可以使用代理模式完成这个要求。 代理模式的作用是：为其它对象提供一种代理以控制对这个对象的访问。在某些情况下，一 个客户不想直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介作用。 代理模式一般涉及到三个角色： 抽象角色

装饰器模式： 可以动态的添加，修改某一个类的功能 特点： 1：创建一个可以被其他类可以实现的类 2：创建一个功能类去实现刚才定义的类 发现： 装饰器模式与观察者模式，适配器模式，这几种模式存在着一定的相似关系 代码： //定义一个可以实现的类 interface decorator { public function before ( ) { } public function after ( ) { } } /** * 颜色装饰器 **/ class Color implements Decorator { protected $color ; //构造器 public function __construct ( $color ) { $this - > color = $color ; } //前置操作 public function before ( ) { echo "<p style='color: { $this - > color } '>" ; } //后置操作 public function after ( ) { echo "</p>" ; } } $color = new Color ( "#000" ) ; $color - > before ( ) ; $color - > after ( ) ; 来源： CSDN 作者： long shen 链接：

装饰器模式可以在不修改原有代码的情况下给它增加一个或多个顺序可变的扩展功能，且不破环原有代码的封装性，使用了OOP的组合+继承的方式来实现，是一种AOP编程思想的设计模式。 现有如下代码： //学生基类 public abstract class StudentBase { public string name { get; set; } public abstract void EatFood(); } //学生子类1 public class StudentClassOne: StudentBase { public override void EatFood() { System.Diagnostics.Debug.WriteLine($"{name} 开始吃东西了"); System.Diagnostics.Debug.WriteLine("吃西瓜"); } } 此时业务逻辑开始发生变化，比如：小花同学还想 吃苹果、吃梨、吃车厘子；这个时候你可以在“吃西瓜”后面加一些代码来实现，但这样每当业务发生变化的时候都要重新修改原有代码， 破坏了代码的封装性，而且不能实现”不同业务场景下吃的东西不一样，或者吃的顺序不一样“的情况。这个时候就要用到我们的装饰者模式了： //声明一个装饰者基类 public class StudentDecorator: StudentBase {

装饰模式，动态的给一个对象添加一些额外的职能，就增加功能来说，装饰比生成子类灵活。 基类component；concreatecomponent继承自component；decorator继承自component，其有成员变量 protected component类型的，有setcomponent（component a）函数对componnet的对象进行修饰；然后再有继承自decorator的类，就是具体的装饰对象，起到对component添加职责的功能。 装饰模式是利用继承类的参数是基类对象的函数，对基类的继承类进行包装的。 来源： CSDN 作者： Best_wxw 链接： https://blog.csdn.net/Best_ideal/article/details/103837909

装饰器模式概述 装饰器模式也称为 包装模式 ，适用于在不改变原有类的情况下，增强类对象的功能 UML 结构 组件接口 ：定义组件应有的功能 具体组件 ：实现了组件接口，需要被装饰的对象 装饰器 ：抽象类，引用和实现组件接口，默认调用组件类的operation方法，也可在组件原有功能的基础上进行增强 具体装饰类 ：继承自装饰器抽象类，通过重写组件类的operation方法，增强其功能并调用父类的operation方法 代码 package com.hpp.decorator; public interface Component { public void operation(); } package com.hpp.decorator; // 具体的组件类 public class ConcreteComponent implements Component { @Override public void operation() { System.out.println("正常操作"); } } package com.hpp.decorator; // 装饰类, 继承Component接口, 并声明使用一个Component实例 public abstract class Decorator implements Component { Component component;

装饰器模式 装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。 这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。 1 package ioStudy; 2 3 4 /** 5 * 装饰器模式 6 * 1.抽象接口 7 * 2.具体对象 8 * 3.抽象装饰者 9 * 4.具体装饰者 10 * */ 11 public class DecorateStudy1 { 12 13 public static void main(String[] args) { 14 Drink coffee = new Coffee(); 15 16 Decorate milk = new Milk(coffee); 17 System.out.println(milk.info()+"===>"+milk.cost()); 18 19 Decorate sugar = new Sugar(coffee); 20 System.out.println(sugar.info()+"===>"+sugar.cost()); 21 22 milk = new Milk(sugar); 23 System.out.println(milk.info()

1.day 10 内容复习 # 之前做得的题 以后再遇到能保证会 # 下周二考 ：所有的知识 # 面试题：认真对待 # # 三元运算符 # 接收结果的变量 = 条件为真的结果 if 条件 else 条件为假的结果 # 接收结果的变量 = “真结果” if 条件 else “假结果” # # 命名空间 和 作用域 # 三种：内置 全局 局部 # 作用域：全局 局部 globals() locals() # global 在局部声明一个全局变量 # nonlocal 在局部声明最近的上一层局部中的变量 # 作用域链 ： 小范围用变量的时候，先从自己的名字空间找， # 找不到就一层一层向外层找，知道找到为止。 # 找不到就报错。 # 函数的嵌套调用和嵌套定义 # 定义在函数内部的函数不能被外界直接调用 # 内部函数可以使用外部的变量 # 函数名的本质 # 就是一串内存地址 # 可以赋值、可以作为容器类型的元素、函数的参数和返回值 —— 第一类对象 # 闭包 ： 内部函数使用外部函数的变量 def outer(): a = 1 def inner(): print(a) return inner i = outer() i() 2.作业讲解 1 # 2、写函数，接收n个数字，求这些参数数字的和。 2 def sum_func(*args): 3 total = 0 4 for i in

Java IO流学习总结 Java流操作有关的类或接口： Java流类图结构： 流的概念和作用 流是一组有顺序的，有起点和终点的字节集合，是对数据传输的总称或抽象。即数据在两设备间的传输称为流， 流的本质是数据传输，根据数据传输特性将流抽象为各种类，方便更直观的进行数据操作。 IO流的分类 根据处理数据类型的不同分为：字符流和字节流 根据数据流向不同分为：输入流和输出流 字符流和字节流 字符流的由来： 因为数据编码的不同，而有了对字符进行高效操作的流对象。本质其实就是基于字节流读取时，去查了指定的码表。 字节流和字符流的区别： 读写单位不同：字节流以字节（8bit）为单位，字符流以字符为单位，根据码表映射字符，一次可能读多个字节。 处理对象不同：字节流能处理所有类型的数据（如图片、avi等），而字符流只能处理字符类型的数据。 结论：只要是处理纯文本数据，就优先考虑使用字符流。 除此之外都使用字节流。 输入流和输出流 对输入流只能进行读操作，对输出流只能进行写操作，程序中需要根据待传输数据的不同特性而使用不同的流。 Java IO流对象 1.输入字节流InputStreamIO 中输入字节流的继承图可见上图，可以看出： InputStream 是所有的输入字节流的父类，它是一个抽象类。 ByteArrayInputStream、StringBufferInputStream