设计模式

开闭原则-对扩展开放，对修改关闭。 开闭原则要求在扩展新功能时应当避免对旧代码的改动。但现实的开发中，新增功能多数情况下都要涉及到旧代码的改动，这主要是因为在业务刚开始推进的时候并不能很清晰的看出业务的拓展方向，因此通常情况下都不会进行预留扩展的设计（避免过度设计）。 当扩展需求出现时，就是开始重构原有代码的时机，而开闭原则就是指导重构的主要思想，在重构过程中，应将此次扩展的业务方向做一个通用方案的处理，保证下次再出现同类型的扩展可以做到不改动或少改动旧代码。 依据开闭原则做架构设计时，我们应该清楚要保护什么，可以通过分层来决定保护级别，最高层的保护级别最高，最低层的保护级别最低。低层级的改动不会影响高层。 层级的划分可以根据业务来划分，核心业务逻辑应该是最高等级，其他层级根据与核心业务的关联程度依次向下划分等级。这样的划分逻辑我们能够保证核心业务规则不会因为其他相关模块的改动而受影响。 接下来通过《架构整洁之道》(clean architecture) 中的一张图来解释一下分层设计 图 8.2 < I > 表示接口，< DS > (data struct) 表示数据类，数据类的特性是第一次访问的时候会创建类，后续则是对该实体的读操作（实体类特性也是如此）。空心箭头表示对应接口的实现，实心箭头表示依赖关系， A->B 则是 A 依赖 B，A 知道 B 的存在，B 对 A 一无所知。 正是由于依赖的这种特性，我们可以把被保护的代码，写到被依赖的类中，这样被依赖的类不会以为依赖方代码的改动而受影响。 上图中：Interactor > (database) > Controller > Presenter 关于图 8.2 调用链路如下： 这种设计 Controller、Presenter、Database 任何模块代码的改动，都不会影响 Interactor ，从而达到了对 Interactor 代码的保护，如果某天对 Presenter 中的 PDF View 进行改动出现了 bug，仅仅印象 PDF View 这一个功能，把 bug 进行最大程度的隔离，实现功能的稳定。 总结 开闭原则保证了程序的扩展性，同时用分层的思想设计架构，通过依赖保护核心业务逻辑，避免核心逻辑的频繁改动，隔离低层代码的改动影响高层。 如果你对架构设局同样感兴趣，推荐给你一本书《架构整洁之道》(clean architecture) 。这本书对架构设计的讲解十分深刻，相信你也一定会有所收获。

面向接口编程： 当一个实体依赖另一个实体时，不依赖实体而是依赖实体的抽象。 比如说生产一个电灯，电灯需要一个开关来控制电灯的点亮和关闭，如果电灯依赖某个具体的开关,，比如电灯出场内置开关依赖了 A 品牌，当有一天买电灯的客户家里是 B 品牌的开关，那么电灯就没办法使用了。但是如果我依赖的是开关的抽象接口，它提供打开和关闭两个行为给电灯，电灯根据打开和关闭的行为去控制电灯的点亮和关闭。 这种设计可以让生产的电灯适应市面上的所有开关，那怕未来实现了脑机接口的开关，只要这个它遵循开关的抽象提供打开和关闭两种行为，这款电灯就能受这种新开关的控制。 从上面例子上可以看出，所谓的接口是依赖双方提前的一种约定，依赖方按照这种约定去调用，被依赖方按照这种约定去实现，这种约定其实就是标准化，调用方按照约定去实现功能，使用方按照约定去使用功能。 标准化的好处 从上面的例子中可以看出，标准化带来最大的好处就是复用，你可以任意的生产各种各样的开关，只要是按照标准制定的，我的电灯都是可以使用的。 其次标准化会带来效率的提升，现实中交通规则就是一个很好的例子，交规就是一个标准, 只要是在路上的走的，都受到交规的约束，而正是有了这种约束我们才有了更高效的通勤，绿灯了可以走，红灯了，就停下来等待，我们对路上所有的车辆和行人的轨迹都有预期，从而提升通行效率。 可以设想一下没有交规，是一个什么样的场景，大概率会出现所有车辆堵在了路口，整个路口堵的水泄不通，最后整体通行效率变得无比低下。 标准化还会带来工具化，再拿生活中常见的交通为例，有了完善的交通规则，后续就可以生产适用这种规则的自动驾驶车辆，这将大大改善人们的出行效率。 标准化在工作中的用处 标准化在工作中也有着十分重要的作用，如今的工作大多都会有工种之间的划分，工种和工种之间就存在着依赖关系，上一个工种的工作要到什么程度，下一个工种应该怎么衔接，这就是一个依赖，而在这两个工种之间就需要一个明确的约定。 有了这种约定，可以减少很多不必要的沟通，不需要去关心上个工种的实现细节，只需要双方按照约定各自生产，在产品成型阶段把各个工种生产出的设备进行组装即可。 当公司来了新人的时候，他也不需要重新去每个环节去了解其他工种的产品特性，只需要去了解约定的标准化制度即可投入到生产中。 标准化的问题 标准化也并非都是好处，它在设计阶段需要投入相当的人力去设计，并且需要在后续的生产阶段通过实践中得到的反馈，去不断的完善标准。 如果标准设计的不好，频繁的变更标准，将会导致所有依赖的标准方都要进行变动，这种变动的成本是相当高的。 因此在标准设计的时候要进行必要的论证和演练，确保标准没有明显的问题，最大限度的减少标准化带来的成本。 总结 标准化相当于在一个有限范围内设计了一个小型的生态系统，标准化制定了基本的流程和规则，生态系统的其他元素按照这种流程和规则去演化出标准化所期望达成的效果。 标准化的制定是有难度的，有些时候仅从设计阶段，无法看到最终的结果，这时可以通过抓大放小的形式去解决。刨除细节，去设计整体框架，保证大方向的正确，在标准化实践的过程中去不断的丰富细节，完善标准，从而让标准化实现最终的落地。 可能某些情况下理想下的标准化永远也无法达成，但这不能成为放弃标准化的理由，不能因为我们理想是得到 100 分的好处，因为我们拿不到 100 分就放弃。拿不到 100 分，能拿 60 分也比一分都没有要好一些，你觉得呢？

单一职责原则：一个模块的功能只能因为一个原因进行修改。 单一职责介绍 我们假设一个场景： 有一个动物类，它会呼吸空气，用一个类描述动物呼吸这个场景： class Animal{ public function breathe(string $animal){ echo $animal . "呼吸空气"; } } $animal = new Animal(); $animal->breathe("牛"); $animal->breathe("羊"); $animal->breathe("猪"); 当有一天我们发现并不是所有的动物都呼吸空气，例如水生的动物他们呼吸的是水，我们就需要进行如下的代码改动。 class Animal{ public function breathe(string $animal,string $type){ if ($type == "terrestrial") { echo $animal . "呼吸空气"; } else { echo $animal . "呼吸水"; } } } $animal = new Animal(); $animal->breathe("牛","terrestrial"); $animal->breathe("羊","terrestrial"); $animal->breathe("猪","terrestrial"); $animal->breathe("鱼","aquatic"); 上述代码的改动就违反了单一原则，breathe 方法会因为两个因素造成修改，分别是 terrestrial 和 aquatic 。 这种违反会带来什么问题，最直观的问题就是会更容易造成 bug, 比如我们 terrestrial 需要增加新的功能，在些新功能的时候引入了一些 bug ，这将导致 aquatic 的代码块也无法执行，具体例子如下：...

日常开发中经常会遇到单例模式的使用场景，单例模式可以保证我们初始化出来的结构体只有一个，在一些请求上下文，mysql 连接池..场景经常有着不可估量的作用。 在 golang 开发中，我们应当如何去设计单例模式呢？ 常见的错误书写方式 相信如果你对 PHP 写的比较多的情况下经常会写出下面代码一样的单例模式 package main type Singleton struct { } var ins *Singleton func GetIns() *Singleton { if ins == nil { ins = &Singleton{} } return ins } 那上述代码，在正常开发存在什么样的问题呢？上述代码如果用于 PHP 项目是没有任何问题的，因为 PHP 本事是请求隔离的，因而也不会存在并发的问题，但是如果放在常驻内存类型的语言中就会出现并发性不安全问题。 接下来考虑一个场景，在高并发场景下，同时又两个业务都执行到 ins == nil 而此时的 ins 确实没有实例化，那程序将会如何执行呢？答案显而易见，两个业务都会实例化出自己的 ins 结构体，这显然不符合我们的程序预期。 如何解决 golang 标准库sync中找到了Once类型。它能保证某个操作仅且只执行一次。有了他我们就可以很方便的解决并发的问题了接下看看代码示例： package main import "sync" type Singleton struct { } var ins *Singleton var once sync.Once func GetIns() *Singleton { once....