qq_53267860的博客

中介者模式算是聚而歼之的模式，因为从分而治之上讲，对应的操作应该让每一个Colleague自行管理，但这样做，Colleague之间需要相互了解，沟通成本太高。如果收拢到Mediator，整体效率会高很多，但Mediator存在成为上帝类的可能，反而导致不好维护。这是不是特别像实际生活。所以说世上的处理方案没有定法，能够更好的解决问题就是最好的。共勉。

解释器模式主要是分而治之，将翻译功能分开管理，方便维护。翻译器模式理解难度和使用难度不大，主要是使用场景比较受限。

设计模式是为了解决现实中的问题，我们需要和具体场景相绑定。在解决问题的时候，采用的是不是标准的设计模式并不重要，模式只是手段，手段需要为达成目的服务。

简单写了一个小功能，还是挺麻烦的，我想这也是大家不太想用设计模式的一个原因。但是当使用的时候，却发现这个设计模式能够方便的实现很多功能，这也是有人想用设计模式的原因。备忘录模式虽然不常用，但是对合适的场景还是很有帮助的。

表示一个作用于某对象结构中的各元素的操作。对象结构中的各元素：就是指一个类和类里的各种成员变量，对应UML中的Element。操作：就是指访问者，访问者有操作元素的能力。所以这句话可以解释为：访问者模式，就是访问者可以操作类里的元素。再看定义：它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。这句话主要讲访问者模式的优点：类在不做任何改动的情况下，能够增加新的操作/解析方式。如元素类是pdf资源文件类，以前只支持抽取文本内容操作，现在增加压缩、提取文件元信息操作，元素类无需感知。

迭代器模式可能对于大部分研发同学来说是不需要的，但对于搞基础框架、搞语言的同学来说应该经常会用。对于迭代器模式，并不是说学习怎么使用，更重要的一点是需要感知设计模式的思想内核。

仔细看上面的代码对事件触发状态的转移及动作的执行的改动会很简单可快速增加新的事件增加新的状态也方便，只需添加新的状态类，少量修改已有代码坏处就是类特别多，类里的函数也会特别多，即使这些函数根本无用。不过能获得更好的扩展性，还是值得的。...

通过Gin中间件的例子，可以很好证明职责链的扩展性。简单使用Use增加自己创建的中间件，每一个请求都会被新增的中间件所处理。所以开发者可以方便的增加鉴权、限流、脱敏、拦截等操作。这就是所谓的优雅吧。...

策略模式很好的体现了开闭原则，也说明即使是很小的优化设计，也能给项目开发带来巨大的便利。当然，这种便利会在维护的时候得到充分体现，毕竟谁维护谁知道。

模板模式有两大作用：复用和扩展。其中，复用指的是，所有的子类可以复用父类中提供的模板方法的代码。扩展指的是，框架通过模板模式提供功能扩展点，让框架用户可以在不修改框架源码的情况下，基于扩展点定制化框架的功能。...

实际上，设计模式要干的事情就是解耦。创建型模式是将创建和使用代码解耦，结构型模式是将不同功能代码解耦，行为型模式是将不同的行为代码解耦，具体到观察者模式，它是将观察者和被观察者代码解耦。...

组合模式是对指定场景有用，所以大家能不能用到，完全看运气。这个设计模式满足单一职责原则、开闭原则、里氏替换原则。

享元模式充分说明了抽象的重要性，希望大家能够善用这种模式，优化系统。

门面模式是程序员最常用的一种设计模式了，在架构设计中往往自然而然的就会用到。很好的满足了接口隔离原则和迪米特法则。

适配器模式简单好用，用对了场景能够极大提高扩展性和优雅性。代理模式在不改变原始类接口的条件下，为原始类定义一个代理类，主要目的是控制访问，而非加强功能，这是它跟装饰器模式最大的不同。装饰者模式在不改变原始类接口的情况下，对原始类功能进行增强，并且支持多个装饰器的嵌套使用。适配器模式是一种事后的补救策略。适配器提供跟原始类不同的接口，而代理模式、装饰器模式提供的都是跟原始类相同的接口。桥接模式的目的是将接口部分和实现部分分离，从而让它们可以较为容易、也相对独立地加以改变。...

装饰器模式理解和使用都比较简单，主要通过组合方式实现复用能力，如果组合的变量为接口或者基类，便可实现串联功能。在使用上，首先需要确定复用的功能抽象的比较好，以免使用的时候，发现很多增强功能可以收敛其中。其次判断是否有增强的功能需要串联的情况，如果有的话，使用装饰器模式是十分合适的。装饰器模式体现了开闭原则、里氏替换原则、依赖倒转原则。...

七大设计原则：单一职责原则、开闭原则、依赖倒置原则、接口隔离原则、迪米特原则、里氏替换原则、合成复用原则

封装特性封装也叫作信息隐藏或者数据访问保护。类通过暴露有限的访问接口，授权外部仅能通过类提供的方式来访问内部信息或者数据。它需要编程语言提供权限访问控制语法来支持，例如Java中的private、protected、public关键字。封装特性存在的意义，一方面是保护数据不被随意修改，提高代码的可维护性;另一方面是仅暴露有限的必要接口，提高类的易用性。抽象特性封装主要讲如何隐藏信息、保护数据，那抽象就是讲如何隐藏方法的具体实现，让使用者只需要关心方法提供了哪些功能，不需要知道这些功能是如何实现的。.....

桥接模式符合了开放-封闭原则、里氏替换原则、依赖倒转原则。使用桥接模式，一定要看一下场景中是否有多种分类、且分类之间有一定关联。如果符合的话，建议用桥接模式，这样不同分类可以独立变化，相互之间不影响。...

接下来会通过 golang 实现静态代理，有 Golang 和 java 的差异性，我们无法比较方便的利用反射实现动态代理，但是我们可以利用。实现类似的效果，并且这样实现有两个比较大的好处，一个是有静态代码检查，我们在编译期间就可以及早发现问题，第二个是性能会更好。的注释，我们就会为这个 struct 生成一个 proxy 类，同时实现相同的接口，这个接口就是在注释中指定的接口。接来下我们会简单的实现这个需求，由于篇幅和时间的关系，我们会略过一些检查之类的代码，例如。@proxy 接口名。...

原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。...

其实可以看到，绝大多数情况下直接使用后面的这种方式就可以了，并且在编写公共库的时候，强烈建议入口的参数都可以这么传递，这样可以最大程度的保证我们公共库的兼容性，避免在后续的更新的时候出现破坏性的更新的情况。...

我们这里的实现比较粗糙，但是作为一个 demo 理解 di 容器也足够了，和 dig 相比还缺少很多东西，并且有许多的问题，例如 依赖关系，一种类型如果有多个 provider 如何处理等等等等。当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候，推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。的方式创建对象/接口，当它返回的是接口的时候，其实就是简单工厂模式。由于 Go 本身是没有构造函数的，一般而言我们采用。.

单例模式采用了 饿汉式 和 懒汉式 两种实现，个人其实更倾向于饿汉式的实现，简单，并且可以将问题及早暴露，懒汉式虽然支持延迟加载，但是这只是把冷启动时间放到了第一次使用的时候，并没有本质上解决问题，并且为了实现懒汉式还不可避免的需要加锁。整个方法加锁创建方法时进行锁定双重检锁原子操作实现饿汉模式概念全局变量实现、init加载实现代码实现饿汉式代码实现:单元测试:懒汉式（双重检测）代码实现:测试结果可以看到直接 init 获取的性能要好一些......

代理模式中分为静态代理和动态代理。静态代理需要在编译前就要写好，而动态代理需要在运行时通过反射来实现方法增强。