代码设计之设计模式（一）

设计模式到底是什么，为什么如此让人重视呢？它到底如何去解决我们的问题呢？下面我将分成以下3个部分为大家进行说明：

设计模式是啥？

设计模式是如何解决设计问题的

设计模式解决问题的设计原则

1.设计模式是啥？

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

总的来说，设计模式就是前人的总结的一套写好代码的方法。就像是学霸告诉你的解题技巧，能够更快更漂亮的解出题目。

2.设计模式是如何解决设计问题的

1）寻找合适的对象

面向对象程序由对象组成，选出一个合适的对象，可以帮助我们把我们所需要编写的代码和现实相对应，更好理解代码和进行开发。

2）决定对象的粒度

不同的设计模式针对不同的代码粒度，帮助我们完成对不同层级代码的设计。

3）指定对象接口

设计模式通过确定接口的主要组成成分及经接口发送的数据类型，来帮助你定义接口。帮助我们能好的做到面向接口编程。

4）描述对象的实现

设计模式通过实现接口或继承类等方法来描述类的实现，通过告诉我们如何去实现对象，来让我们的代码写的更好。

5）运用复用机制

设计模式通过运用合理的复用机制，减少代码的复制以及数量，降低运维成本。

6）关联运行时刻和编译时刻的结构

运行时的代码才是我们所需要的，正常我们敲出的代码通过了编译器的检查，但是在运行时还有很多需要注意的问题，设计模式可以把两者进行关联，来写出优秀的代码。

7）设计应支持变化

不支持变化的代码会在后期运维和拓展功能的时候让你心碎。这也是目前领域驱动设计的核心观点，拥抱变化；同时微服务的设计也是为了适应快速需求的变化而生的，所以在设计时这一点很重要。

3.设计模式解决问题的设计原则

1、开闭原则（Open Close Principle）

开闭原则就是说对扩展开放，对修改关闭。扩展开放是说加功能的时候，可以对模块进行扩展，来满足要求；修改关闭，是指添加新功能的时候是不用修改原有的代码。

总之就是程序扩展功能容易，不用修改原有代码就能实现需求。一般是采用接口以及抽象类的方式去实现的，就像Spring中，替换Service实现类，是通过修改注解或配置来实现，不用修改代码。

2、里氏代换原则（Liskov Substitution Principle LSP）

子类能替换父类，并且不影响软件功能。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

3、依赖倒转原则（Dependence Inversion Principle）

这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。就比如我们使用Spring编写web应用，service和dao的使用，都是通过接口来调用，一旦我们需要变更实现方法，我们只需要变更注入的实现类，就可以替换代码，而不是像直接调用实现类那样，一旦变更，就需要修改以前的代码。

4、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。就比如我们在web中经常会使用的BaseDao这个类，里面会有增删查改四个基本方法，但其实增删查改复杂之后，可能会有多种方法，这个时候把增删查改进行拆分，变成4个接口，再由BaseDao继承，会更好管理。

5、迪米特法则（最少知道原则）（Demeter Principle）

为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。就是保证内聚性高，不太会被别的实体所影响。这也是当前微服务所提倡的一点，要保证服务的独立，自治性。

6、合成复用原则（Composite Reuse Principle）

原则是尽量使用合成/聚合的方式，而不是使用继承。继承其实是在破坏类的封装性，一旦父类发生变化，子类所复用的方法全部都要跟着变化，父类和子类就没有做到有效的隔离。

注：总的来说，其实就是高内聚，低耦合。通过面向接口编程，降低模块间的耦合，相互独立，提高代码的扩展性。

本文可能概念比较多，干货相对来说会少一点，但是这些概念是我们使用设计模式的思路以及标准，我们可以做到即使不用设计模式，也可以设计出相对来说比较好的代码。后面笔者会分享23种设计模式的内容，期待大家的阅读。