代码设计原则

什么是设计模式

设计模式是针对软件开发过程中遇到的一些设计问题，总结出来的一套解决方案或者设计思路。

https://zh.wikipedia.org/wiki/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F_(%E8%AE%A1%E7%AE%97%E6%9C%BA)

创建型模式

• 简单工厂模式（Simple Factory）
• 工厂方法模式（Factory Method）
• 抽象工厂模式（Abstract Factory）
• 创建者模式（Builder）
• 原型模式（Prototype）
• 单例模式（Singleton）

结构型模式

• 外观模式（Facade）
• 适配器模式（Adapter）
• 代理模式（Proxy）
• 组合模式（Composite）
• 享元模式（Flyweight）
• 装饰模式（Decorator）
• 桥模式（Bridge）

行为型模式

• 中介者模式（Mediator）
• 观察者模式（Observer）
• 命令模式（Command）
• 迭代器模式（Iterator）
• 模板方法模式（Template Method）
• 策略模式（Strategy）
• 状态模式（State）
• 备忘录模式（Memento）
• 解释器模式（Interpreter）
• 职责链模式（Chain of Responsibility）
• 访问者模式（Visitor）

面向对象

面向对象编程是一种编程方式或者编程风格， 以类或者对象作为组织代码的基本单元。包含封装，多态，继承，抽象等4个基本特性。

面向对象语言

面向对象语言是支持类和对象的语法机制，并有现在的语法机制，能够方便的实现面向对象的4大特征（封装、抽象、继承、多态）的编程语言。封装特性存在的意义，一方面是保护数据不被随意修改，提高代码的可维护性；另一方面是仅暴露有限的必要接口，提高类的易用性。

封装

封装也叫做数据隐藏和数据访问保护，通过暴露有限的访问接口，授权外部仅能通过类提供的方式来访问内部信息和数据。它需要编程语言提供权限访问控制语法来支持， 比如 Java 中的 private 、protected 、public等关键字。

抽象

封装说的是如何隐藏信息和保护数据，抽象说的是如何隐藏方法的具体实现，抽象可以通过接口或者抽象类来实现，但也并不需要特定的语法来支持。抽象存在的意义，一方面是提高代码的可扩展性和维护性， 修改方法时不需要改变定义，减少代码的改动范围，另外一方面也是处理复杂问题的有效手段， 能够有效过滤掉不需要关注的信息。

继承

继承用来表示 类之间 is-a 的关系，分为两种模式， 单继承和多继承，单继承表示一个子类只能继承一个父类，多继承表示一个子类可以继承多个父类，为了实现继承这个特性，编程语言需要提供特殊的语法机制来支持。继承主要是用来解决代码复用的问题。

多态

子类可以替代父类，实际代码运行过程中，调用子类的方法实现。多态这个特性需要编程语言的特殊语法机制来实现，比如继承、接口类，duck-typing， 多态可以提高代码的扩展性和复用性，有很多设计模式，设计原则，编程技巧的代码实现基础。

面向对象和面向过程

• 对于大规模复杂程序的开发，程序的处理并非单一的一条主线，是错综复杂的网状结构，面向对象比面向过程编程，更能够应对这种复杂类型的程序开发。
• 面向对象编程相对于面向过程编程，具有丰富的特性（抽象，继承，封装，多态），利用这些特性写出的代码更加容易扩展，易复用，易维护。
• 面向对象编程比面向过程编程更加人性化，更加智能。

组合与继承

• 继承是面向对象的四大特性之一，表示类之间的 is-a 的关系（Apple is Fruit ) 可以解决代码复用的问题，但是继承如果层次过深，过复杂，也会影响代码的可维护性。
• 组合表示的是类的 has-a 的关系，比如 House has BathRoom 。

类的继承层次如果很深，继承的关系会越来越复杂，而且层次很深很复杂的继承关系，会导致代码可读性变差，子类的实现依赖父类的实现，两者高度耦和，一旦父类代码修改，会影响子类的逻辑。

GO 是面向对象语言么？

Go 围绕 struct ，提供了私有属性、method、interface、struct 嵌套能力，可以用更轻量的方式实现面向对象（封装，继承，多态，抽象）

Go 核心理论

基于接口编程而非实现编程

接口是一组协议或者约定，是功能提供者提供给使用者的一个功能列表，接口在不同的场景下有不同的解读，

好的代码设计，不仅能够应对当下需求，而且在将来需求发生变化的时候，仍然可以在不破坏原有代码设计的情况下灵活应对。

设计原则

如何理解单一职责原则 （SRP)

一个类或者一个模块只负责完成一个职责或者功能，不要设计大而全的类， 要设计粒度小，功能单一的类， 单一职责是为了实现代码高内聚，低耦合，提高代码的复用性，可读性，可维护性。

如何判断类的职责是否足够单一

不同应用的场景，不同阶段的需求背景，不同的业务层面，对通一个类的职责是否单一，可能会有不同的判定结果。

如果出现以下情况，表示不满足单一职责原则：

• 类中的代码行数，函数或者属性过多
• 类依赖其他类过多， 或者依赖类的其他类过多
• 私有方法过多
• 比较难给类取一个合适的名字
• 类中大量方法都集中在操作类的某些属性上
• 代码中存在大量注释

开闭原则

如何理解 “对扩展开放，对修改关闭”

添加一个新功能，应该是通过现有共扩展代码（新增模块，类，方法，属性等）, 而非修改已有代码的方式来完成。

• 第一点，开闭原则并不少说完全杜绝修改，而是以最小的修改代码的代价完成新功能的开发。
• 第二点，同样的代码修改，在粗粒度下，可以被认为是修改，在细粒度下，被认为是“扩展”。

我们对一个类添加新的方法。添加方法相当于修改类，在类这个层面，这个代码改动可以被认定为“修改”；但这个代码改动并没有修改已有的属性和方法，在方法（及其属性）这一层面，它又可以被认定为“扩展”

如何做到修改关闭，扩展开放？

时刻具备扩展意识，抽象意识，封装意识。编码时，要多花时间去思考，代码未来可能哪些需求变更，如何设计代码结构，事先留好扩展点，以便在未来在需求变更时，在不调整代码结构的基础上，做到最小代码的修改，将新代码灵活的放到扩展点上。

最常用的提高代码扩展的方法有：多态，依赖注入， 基于接口而非实现编程，与大部分设计模式。

里式替换

里式替换原则的英文翻译是：Liskov Substitution Principle，缩写为 LSP。这个原则最早是在 1986 年由 Barbara Liskov 提出，他是这么描述这条原则的：If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program。

子类对象能给替换程序中父类出现的任何对方，并且保证程序的行为逻辑及正确性不被破坏。

多态是面向对象编程等一大特性，也是面向对象编程语言的一种语法，它是一种代码实现的思路，里式转换原则设计中，是用来指导继承关系中子类如何设计，子类的设计保证在替换父类时，不改变原有逻辑和程序的正确性。

接口隔离

接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为 ISP。Robert Martin 在 SOLID 原则中是这样定义它的：“Clients should not be forced to depend upon interfaces that they do not use。”直译成中文的话就是：客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。

理解接口隔离重要是理解其中接口两字。接口理解一组接口集合，可以是某个服务的接口，可以是某个类的接口，如果部分接口被有这使用。

接口隔离原则和单一职责原则的区别

单一职责是针对的是类，模块，接口的设计，接口隔离原则相对单一原则更侧重于接口的设计。另外思考角度也不一样。接口隔离原则提供了一种判断接口是否单一的标准：通过调用者如何使用接口来判断，如果调用者使用部分接口或接口的部分功能，那接口的设计就不够单一

依赖倒置原则

控制反转

实际上，控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。这里所说的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。

依赖注入

依赖注入和控制反转恰恰相反，它是一种具体的编码技巧。我们不通过 new 的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类来使用。依赖注入也是实现组合最简单的方式

type A struct {}
func NewA() A {
    return A{}
}
type B struct {
    a A
}
func NewB(a A) B {
    return B{a:a}
}
func main() {
    a := NewA()
    // 依赖注入
    b := NewB(a)
}

依赖反转原则也叫作依赖倒置原则。这条原则跟控制反转有点类似，主要用来指导框架层面的设计。高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。

KISS 原则

• Keep It Simple and Stupid.
• Keep It Short and Simple.
• Keep It Simple and Straightforward.

其实主要含义是尽量保持简单

如何写出 KISS 原则的代码

• 不要使用同事可能不懂的技术来实现代码
• 不要重复造轮子，要善于使用已经有的工具类库
• 不要过度优化

DRY 原则

DRY 原则（Don’t Repeat Yourself）几乎人尽皆知。你可能会觉得，这条原则非常简单、非常容易应用。只要两段代码长得一样，那就是违反 DRY 原则了。真的是这样吗？答案是否定的。这是很多人对这条原则存在的误解。实际上，重复的代码不一定违反 DRY 原则，而且有些看似不重复的代码也有可能违反 DRY 原则。

通常存在三种典型的代码重复情况，它们分别是：实现逻辑重复、功能语义重复和代码执行重复。

问题：如何提高代码复用性？

• 减少代码耦合
• 满足单一职责原则
• 模块化业务与非业务逻辑分离
• 通用代码下沉
• 继承、多态、抽象、封装
• 应用模板等设计模式

LOD 原则

迪米特法则的英文翻译是：Law of Demeter，缩写是 LOD。单从这个名字上来看，我们完全猜不出这个原则讲的是什么。不过，它还有另外一个更加达意的名字，叫作最小知识原则，英文翻译为：The Least Knowledge Principle。

迪米特法则法则强调不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。

“单一职责原则”、“接口隔离原则”以及“最小知识原则”，都是实现高内聚低耦合的有效指导思想。“最小知识原则”更强调类与类之间的关系。