设计模式
常用设计模式
生于四海
一个在科研路上越走越远的猴子
展开
-
设计模式——组合模式
组合模式将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。透明方式在Component中声明所有用来管理子对象的方法,其中包括Add、Remove等。这样实现Component接口的所有子类都具备了Add和Remove。这样做的好处就是叶子节点和枝节点对于外界没有区别,它们具备完全一致的行为接口。但也存在着问题,即对于叶子节点来说,本身不具备Add和Remove功能,所以实现它是没有意义的。安全方式在Component接口中不去原创 2021-01-04 21:34:41 · 313 阅读 · 1 评论 -
设计模式——备忘录模式
备忘录模式在不破坏封装性的前提下,捕获一个对象的内在状态,并在该对象之外保存这个状态。这样就可以将该对象恢复到原先保存的状态Originator类class Originator{ private String state; // 关于对象属性的set get方法.... // 创建备忘录,将当前需要保存的信息导入并实例化出一个Memento对象 public Memento CreateMemento(){ return (new Memento(state)); } // 恢复原创 2021-01-02 15:50:43 · 333 阅读 · 2 评论 -
设计模式——适配器模式
适配器模式将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类一起工作。适配器代码结构Target(客户需要的接口,目标可以是具体或者抽象类,也可为接口)class Target{ public void Request(){ // 普通请求 }}Adaptee(需要适配的类)class Adaptee{ public void SpecificRequest(){ // 特殊请求 }}Adapter(原创 2020-12-24 09:55:37 · 104 阅读 · 0 评论 -
设计模式——状态模式
状态模式当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了它的类。状态模式解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中,可以把复杂的判断逻辑简化。优点:将与特定状态相关的行为局部化,并且将不同状态的行为分割开来,可以消除庞大的条件分支语句。当一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为时,就可以考虑使用状态模式。代码结构State类:抽象状态类,定义一个接口来封装与Context的一个原创 2020-12-19 16:30:19 · 162 阅读 · 1 评论 -
设计模式——抽象工厂模式
抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类。代码实例可以看这篇博客优点易于交换产品系列,由于具体工厂类在一个应用中只需要初始化的时候出现一次,这就使得改变一个应用的具体工厂变得非常容易,它只需要改变具体工厂即可使用不同的产品配置。它让具体的创建实例的过程与客户端分离,客户端是通过它们的抽象接口操纵实例,产品的具体类名也被具体工厂的实现分离,不会出现在代码中。使用反射技术替代繁琐的switch判断等条件判断。为了自己复习方便写的,这篇乱七八糟….转载 2020-12-18 16:56:32 · 148 阅读 · 1 评论 -
设计模式——观察者模式
观察者模式 观察者模式也叫做发布——订阅模式(Publish/Subscribe)模式。 它定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。 这个主题对象在状态发生变化时,会通知所有观察者对象,使他们能够自动更新自己。代码结构Subject类,即主题或者抽象统治者,一般用一个抽象类或者一个接口实现。它把所有对观察者对象的引用保存在一个集合里面,每个主题都可以有任意数量的观察者。abstract class Subject{ private ArrayList<O原创 2020-12-10 12:24:14 · 108 阅读 · 0 评论 -
设计模式-建造者模式
建造者模式将一个复杂对象的构建与他的表示分离,使得同样的构建过程可以创建不同的表示。建造者模式可以将一个产品的内部表象与产品的生成过程分割开来,从而可以使一个建造过程生成具有不同的内部表象的产品对象。如果我们使用了建造者模式,那么用户只需指定需要建造的类型就可以得到它们,而具体建造的过程和细节就不需要知道了。代码结构Product类-产品类具体对应的产品角色class Product{ List<String> parts = new List<String原创 2020-11-26 11:30:51 · 110 阅读 · 1 评论 -
设计模式-外观模式
外观模式为子系统中的一组接口提供一个一致的页面,此模式定义了一个高层接口,该接口使该子系统更加容易使用。代码结构如下// 子系统类class SubSystemOne{ public void MethodOne(){ //...具体实现 }}class SubSystemTwo{ public void MethodTwo(){ //...具体实现 }}class SubSystemThree{ public void MethodThree(){ //.原创 2020-11-22 17:05:34 · 87 阅读 · 0 评论 -
设计模式-迪米特法则
迪米特法则——最少知识原则如果两个类不必彼此通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。在类的设计结构上,每一个类都应当尽量降低成员的访问权限即一个类包装好自己的private状态,不需要让别的类知道的字段或行为就不要公开。迪米特法则的根本思想:强调类之间的松耦合类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成波及。...原创 2020-11-21 16:44:27 · 76 阅读 · 0 评论 -
设计模式-模板方法模式
模板方法模式定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。代码结构如下:AbstractClass:抽象类,即抽象模板,定义并实现了一个模板方法。 abstract class AbstractClass{ public abstract void PrimitiveOperation1(); public abstract void PrimitiveOperation2(); public v原创 2020-11-16 11:11:32 · 77 阅读 · 0 评论 -
设计模式-原型模式
原型模式用原型类型指定创建对象的种类,并通过拷贝这些原型创建新的对象。原型模式其实就是从一个对象再创建另外一个可定制的对象,而且不需要知道任何创建的细节。代码框架如下 // 原型类 class ConcretePrototype1 extends implements Cloneable { private String id; public Prototype(String id) { this.id=id; } public String getId(){原创 2020-11-15 14:32:13 · 126 阅读 · 0 评论 -
设计模式-工厂方法模式
工厂方法模式简单工厂模式:工厂类中包含了必要的逻辑判断,根据客户端的选择条件动态实例化相关的类,对于客户端来说,去除了与具体产品的依赖。但是在我们添加功能的时候,就要修改原有的工厂类去添加分支判断条件,即不但扩展开放,修改也开放了,违背了软件设计中的开放-封闭原则。工厂方法出现。工厂方法模式定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到子类。Product接口:定义工厂方法所创建的对象的接口ConcreteProduct:具体的产品,实现了P原创 2020-11-13 14:00:28 · 73 阅读 · 0 评论 -
设计模式-代理模式
代理模式为其他对象提供一种代理以控制对这个对象的访问结构如下Subject类:定义RealSubject类和Proxy类的公用接口,可以使得在任何使用RealSubject类的地方都可以使用Proxy类 public interface Subject{ void request(); }RealSubject类:定义Proxy所代表的真实实体 public class RealSubject implements Subject{ @Override publi原创 2020-11-12 14:24:25 · 56 阅读 · 0 评论 -
设计模式-装饰模式
装饰模式动态地给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活装饰模式是为已有功能动态地添加更多功能的一种方式优势:把类中的装饰功能从类中搬移取出,可以简化原有类有效地把类的核心职责和装饰功能区分开来,去除重复的装饰逻辑代码示例// 人物类class Person{ private String name; public Person(){ } public Person(String name){ thi原创 2020-11-10 13:37:25 · 132 阅读 · 0 评论 -
设计模式-面向对象程序设计原则
单一职责原则尽量让每个类承担很少的职责,减少代码的耦合程度对于一个类而言,应该仅有一个引起它变化的原因如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。对于软件设计开发而言,要判断职责能否分离,即如果能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责。开放-封闭原则对于一个实体(类、模块、函数)来说,应该是可以扩展,但不可修改对于扩展开原创 2020-11-09 15:14:34 · 157 阅读 · 0 评论 -
设计模式-简单工厂模式+策略模式
面向对象的分析设计编程思想:通过封装/继承/多态把程序的耦合度降低使用设计模式让程序更加灵活/容易修改/易于复用简单模式核心思想为:使用一个单独的类来做这个创造实例的过程,即工厂...原创 2020-11-02 21:39:29 · 202 阅读 · 0 评论