godme

责任链模式模式对比桥接模式：都有占位；但是桥接更注重唯一位置策略模式：都有执行策略；但是策略模式一般都是单选，而且策略固定状态模式：可能有多重策略流转；不过状态动态，且顺序执行组合模式：都有递归遍历的形态；但是组合更多在于数据结构装饰器模式：都有封装扩展；但是责任链上下文一致和众多的设计模式相比，比起结构管理，责任链模式更多的在于功能管理。泛化是设计模式的普遍特征，因此，复杂的功能经常都是由一个起点引发的关联执行。这是一种深度的发展、分支的发散。设计模式中也不乏横向的变化，但是都有一

命令模式模式对比如果选最相似的几个设计模式，那必定是桥接模式：直接内核调用观察者模式：直接通知他们都毫无疑问的做到了一点：直接执行。命令，不就是应该直接执行的么。至于怎么处理，与我无关。代码示例interface Command { void execute();}class Invoker { List<Command> commands = new LinkedList<>(); public void addCommand

解释器模式模式对比顾名思义，解释器模式重在解释。如何解释？和其他模式对比一下策略模式：选择哪一个策略进行执行呢状态模式：什么状态了，该用哪一个回调进行执行可以看到，它的解释更多是需要告诉程序如何进行执行，至于其中包含的条件操作数据…明显不是在较为狭窄的空间内的选择。代码示例 public static void main(String[] args) { String stringExpression = "'hello ' + #name + ' !

迭代器模式模式对比设计模式之间差异真的很微妙，可以说它是基于更细粒度的准则聚合的规范。设计模式的差异主要来源于针对的场景，目的不同则体现不同。享元模式、原型模式和备忘录模式之间可见一斑，其他的就不一一列举。而每种设计模式之间，还可以相互进行组合、嵌套，实在妙用无穷。但是，需要对每种设计模式的针对功能有明确的认知。对于迭代器模式，主要便是用于数据的迭代。组合模式：同样是针对数据进行管理，但是体现方式差异巨大观察者模式：组播情况使用可使用迭代器模式，不过针对性不同可以说，迭代器模式并不复

中介者模式模式对比最典型的莫过于房产中介了，熟悉两端，两端交互，两端收费。从设计模式中找出相似的模式并不容易，而且差异不小代理模式装饰器模式具体行为都不用详细对比，因为它明确的就只有单向调用。其他设计模式也有回调这种形态，但是功能上没有更多的转发和管理。更相似应该算是桥接，但是调用链其实还是单向的。中介者自身的特质也能够直白的体现出来：传声筒。但是传达过程中的其他操作和管理，这也是我们能够利用的空间。代码示例class Wechat { Map<String, Us

备忘录模式模式对比首先说明一下备忘录的本质：副本备忘，当主体销毁或者变动，能够进行之前状态的恢复。这样一来，就能够随便抽取几个设计模式进行对比缓存模式：缓存，本身可以当做副本的一种原型模式：非引用的实现，也是副本策略模式：因为状态的变化，副本并不一定唯一可以看到，备忘录模式的核心在于副本和状态。值的一提的是享元模式，因为享的定义是直接地引用而非复制，需要区分。代码示例class Note { Stack<String> copies = new Stack&l

观察者模式直觉背反不能顾名思义，观察者模式是反直觉的，它的本质刚好和名字相反。与其说是观察，核心其实在于通知。这也不能说是故意为之，相比较与pull的监听，push实现起来不仅简单，而且节约资源。虽说是监听xxx，本质上却是xxx主动通知。模式对比如果非要斤斤计较，能找到很多相似的设计模式，不过也只是部分相似桥接模式：整体模式还是基于占位+回调，但是观察者模式的占位并非一个，而是一堆。至于回调，观察者模式中都是信息传递，具体的功能一般都不包含。策略模式虽然都有多种相同形式的回

状态模式状态机#mermaid-svg-SjBMBewgnKUitBTe .label{font-family:'trebuchet ms', verdana, arial;font-family:var(--mermaid-font-family);fill:#333;color:#333}#mermaid-svg-SjBMBewgnKUitBTe .label text{fill:#333}#mermaid-svg-SjBMBewgnKUitBTe .node rect,#mermaid-svg-S

策略模式模式对比从可替换的角度而言，由于设计模式都是基于接口抽象的，相似的实在太多。不过唯一剔除的就必须是模板方法了，因为是外部控制策略，并非原有逻辑本身。但是唯一的不同，就是策略二字。不论是代理模式还是装饰器模式，亦或是其他，都只能说是为策略留有余地。而策略模式，其实就是策略本身。还有一点最大的特点，就是它的决策和动作是分离的。就好比对象实体和指针引用一样，两方面都能很好的管理。和其他模式对比，它严格的又两个部分。注册表把实体和名称分离以后，就是存粹的策略逻辑了。Windows中

模板方法模式对比光从作用上进行对比，如下的涉及模式都可以完成类似的工作桥接模式：实现占位，根据传入内核进行调用装饰器模式：同代理模式，我们也可以实现装饰，不过必须返回占位对象的子类代理模式：代理指定(空)方法AOP：只是定位的方法不同，本身归于代理模式继承绑定即使有太多可以类比的设计模式，但是有两道坎是绕不过去的功能：内部或者外部功能的区分，这里实在的把代理和装饰剔除了，因为它就是功能本身，而非外包装继承：这就是完全区别于其他独立抽象的设计模式了，模板方法是强依赖继承的

访问者模式五马分尸如果了解GO或者RUST，你会发现一些比较有意思的东西，尤其是在数据结构声明的时候。在JAVA中偶尔会有一些思考，关于的就是对象方法和接口行为的理解，两者不同，却又似乎差异不大。在GO和RUST中，数据结构的声明和方法是分离的，甚至方法都不一定要归属于同一个代码块。很好理解这样的意图：能够为基础的数据结构快速增加额外的行为。不过数据结构最好稳定一些，详细分析后面说到。函数式编程函数式编程中，函数是作为第一等公民。JAVA支持函数式编程么，说实话，一直都能，但是一直都很

代理模式模式对比说到代理模式，不得不拿出来对比的还有如下几种设计模式桥接模式：填充内核，直接调用内核，在意内核的可替换性，讲究广度装饰器模式：直接调用内核，但是功能深层定制，讲究深度如果说桥接模式主要是在于结构，装饰器模式核心在于功能，那代理模式核心就是管理了。同样的内核调用，但是侧重点不同，使用方式也不同。举个例子 @Transactional public void tx(){ // doSomething }具体就不用多说了，后面的使用分

享元模式相似对比享元模式，顾名思义，是共享元数据，与此相同的还有其他模式，但是各有特点原型模式：强调单一类型的复制操作，直接引用、内存拷贝、对象创建等多种方式。缓存模式：直接将对象进行缓存，需要时直接进行获取，属于引用一类。享元模式：部分数据缓存复用，而其他数据需要额外维护，有范围的区分。举个例子 public static Integer valueOf(int i) { if (i >= IntegerCache.low && i <=

门面模式外部抽象门面模式不算新的东西，还是抽象那一套顶层抽象：大多设计模式都是面向抽象接口的动作封装动作组合：一般接口都是这样功能组合：抽象工厂也是提供一堆的组合功能组合功能明确简洁明了：接口都是简洁且直接地，并且都是直观的功能完备：每个接口都在自身的范围内闭环值的一提的是它所谓的功能，并非所谓的小功能，而是针对一个复杂系统的完备API。并非是小模块、小组件、小工具的小打小闹，而是真实的系统级别的接口。在这个前提下，保证简单通用完备举个例子public

装饰器模式功能定位有必要将装饰器模式和适配器模式与桥接模式对比一下，这三者真是失之毫厘谬以千里，可谓妙到毫巅。桥接模式：快速内核替换；属于单类型横向扩展适配器模式：多功能接口转换，对齐双端结构；属于单接口单点转换器装饰器模式：单点功能装饰，深度定制；属于单类型的纵向扩展；并且天然具有串联属性常见例子 public static void main(String[] args) { InputStream inputStream = System.in;

组合模式数据管理设计模式是结构管理，但是组件化和抽象的思想并不总是直接针对接口。针对数据的模块化管理，也是设计模式的任务之一。想象一下公司的组织架构图，想象一下服务架构图，这些都是数据管理，却划分成了不同的部门、模块。而抽象成一种简单的表现形式，就是不断的层级嵌套，这就是组合模式的样式了。树形结构public interface Container { void addComponent(Container container); void draw();}public

桥接模式替身之术如果说前面的适配器模式是系统信息的对齐，那桥接模式可以说是信息传递的缓冲。在前面的几种设计模式中，针对抽象我们的描述是一种占位，可以切换实现来完成不同的工作。但是在很多场景中，我们的切换也需要一定的策略，缓冲能够很好地将这一层进行分离，单独管理.不过，和硬性的策略制定不同，有些时候我们需要的是及时的替换，此时桥接模式就能够大显身手了。桥接一下interface ExecuteService { void execute(Runnable task);}inter

适配器模式石油交易布雷顿森林会议使得美元和黄金挂钩，后续的石油交易也沿用了美元进行交易。也就是说，你想买石油，需要使用美元进行结算。如何使用人民币进行石油交易呢？显然，首先使用人民币进行美元的兑换，然后使用美元进行石油的购买。这也是适配器模式的作用，沟通两个不对等接口，使其保持沟通。简单例子interface Transfer { void transfer();}interface BankTransfer { boolean auth(); void t

原型模式作用原型模式可以单纯的理解为统一源头：从一个标准的源派生出一个的对象。核心在于快速的获取一个对象的实例，更多功用在于实现逻辑上的区别。场景多处修改针对单一对象，在多处代码中进行属性修改。可以是使用原型模式进行快速的获取副本，独立的进行修改。副本创建对于一个频繁创建单一对象的场景，可以直接使用原型拷贝，然后进行差异点修改，避免从新创建对象开销。快速复制对于对象的拷贝，基于内存拷贝比从头创建一个对象、设置属性更加快速。优势它的功用的确十分简单，纯粹的就是对象复制，关键

工厂模式抽象不论是抽象类，还是接口，它最大的作用就是占位，根据替换不同的具体实现，达到后期扩展的目的。此时，凸显出了两个问题选择策略的管理对象创建的管理针对对象创建这个问题，如果零散的进行创建，后期的维护势必显得困难。好在如今的IOC框架的多样，使得我们关注关联关系即可，对象的创建都收归在了一处。还有一个问题在于，抽象的占位，并非只能够接入一个具体的实现，它只是一次只能一种罢了。针对具体实现的切换、选择，这部分的选择策略如何进行管理呢。public class CarFactory

建造者模式一个例子class Person { private String name; private String gender; private Integer age; public static Person builder(){ return new Person(); } public Person name(String name){ this.name = name; return th

单例模式基础单例饿汉模式public class Single { private static final Single INSTANCE = new Single(); public static Single getInstance(){ return INSTANCE; }}懒汉模式public class Single { private static final Single INSTANCE = null; pu

观察者模式饿了要吃饭，累了要休息策略模式中，我们根据一个条件来判定状态，然后选择具体的处理策略。这是官方的，必要的，明确规定的流程，更是业务的明确需求。同时，还有模板方法让我让我们进行流程填充。更多的不必赘述，纵观之前的模式，都是选择，但是有时候，我们更需要触发。正如开篇，饿了要吃，累了要睡，我们知道如何去吃、如何去睡，但是，我们的状态怎么知道呢。或者可以使用策略模式来无限监听Created with Raphaël 2.2.0startprocesserror?endtrigger

模板方法说道模板方法，不得不回顾一下策略模式和外观模式。策略模式可替换核心策略。功用在于多业务场景下的通用流程收束，降低流程复杂度。功能定位为主流程中的可切换操作。外观模式完整产品观感。针对一种特定功能的完整业务流程规划，具体功能依赖底层实现。功能定位为收束一种类型的产品，使用同一的办法进行使用，不同场景切换核心实现。明显的感受到，两者似乎都是同样的东西，但是从产品和业务两个角度上看，差异不小。外观模式属于产品，在一定场景下，基本上是固定的，不需要也不可能进行频繁更换。策略

外观模式画皮画虎难画骨，知人知面不知心相同的外观下，蕴含丰富的内涵，甚至迥异的操作，这就是外观模式。前面我们实现的几种模式，常说的有一点，保证外部API的单调性。外观模式就是这样的东西，或者换一种说法：面向接口编程。当我专注于流程和组织的时候，使用接口构建出纯粹的抽象业务，此时，我可以说我的工作完成了。因为业务流程的确如此，但是涉及到不同的细节场景，每种的具体处理有时候天差地别。让每个业务线的人员自行去进行填充实现就好了。著名的slf4j，本身就是个空壳子，如果不引入具体实现的包，真

策略模式策略模式是啥，就是选择，或者说是操作的选择。def calc(operation, a, b): if operation == "add": return a + b elif operation == "sub": return a - b elif operation == "mul": return a * b elif operation == "div": return a / v raise Exception(f'unknow

class@Datapublic class Person{ String name; int age;}工厂模式工厂模式谁都听过，不过实际运用的时候从来都不是基础的那个模样。public class PersonFactory{ public Person newPerson(){ return new Person() }}单例模式public class PersonFactory{ private final Person uniqPerson