设计模式白话说 | 什么是设计模式？设计模式有什么好处？如何高效学习设计模式？

简介：为什么要开展设计模式这个专栏？设计模式对于开发而言无疑是一把‘神兵利器’的存在【用不好也是伤敌一千自损八百】。在JAVA底层包的源码，各大流行框架的代码设计中充满了设计模式的踪迹。无疑，掌握了设计模式，无论对于代码开发设计或阅读框架源码都是很有好处的。【难道你不想隔壁MM同事投来看大牛的目光么😁】

1. 什么是设计模式

设计模式（Design Pattern）是敲代码前辈们总结出对于代码的可复用性、可维护性、可读性、稳健性以及安全性的解决方案，是解决特定问题的一系列套路。帮助项目代码构建起一座坚实的地基，在后续修改原有功能时，避免出现牵一发动全身的蝴蝶效应

刚开始看设计模式代码感觉花里胡哨的。本可以通过一个简单方法完成的功能，使用了设计模式的方式创建了很多类，上跳下窜的经过了多个步骤才完成了功能，相对于平常CODING，设计模式的代码会更多

设计模式编写的代码确实繁琐，不过本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性，以及类的关联关系和组合关系的充分理解

2. 设计模式的好处

帮助代码设计拥有可复用性、可维护性、可读性、稳健性以及安全性

使用了设计模式的代码都拥有高内聚、低耦合的特性。什么是高内聚？什么是低耦合？

2.1 高内聚、低耦合

以公司的模式举例子。比如说研发部只负责系统的代码开发，人事部负责对人员进行招聘以及处理公司的一些事宜，公司中不同部门一般都是只负责一类事情。在软件开发中可以映射为，用户模块只负责用户的一些操作，不会出现财务流程相关的操作，这种称之为 高内聚，这一点和 单一责任原则 很相似

低耦合 模式的意思就是要我们尽可能地减少类之间的连接。低耦合降低了因一个类的变化而影响其他类的范围，低耦合使类更容易理解，因为类会变得简单，更内聚。另外，不需要通信的两个对象之间，不要进行无谓的连接，连接了就有可能产生问题

3. 六大基本原则

3.1 开闭原则（Open Close Principle）

对扩展开放，对修改关闭。 在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类

3.2 里氏代换原则（Liskov Substitution Principle）

尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口。子类可以扩展父类的功能，但不能改变父类原有的功能

3.3 依赖倒转原则（Dependence Inversion Principle）

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体

// 面向接口编程
Animal dog = new Dog();
// 面向具体实现编程
Dog dog = new Dog();

3.4 单一职责原则（Single Responsibility Principle）

一个类只承担一个职责，不要让一个类承受的事情过多

总的来说：引起这个类引起变化的原因只有一个

比如WEB系统中的权限类，不要管用户相关的事宜。相当于不同模块间操作内容进行隔离

3.5 接口隔离原则（Interface Segregation Principle）

接口最小化。接口中的方法应该尽量少，保持定义接口时的语义。和单一职责原则类似

单一职责针对的是类
接口隔离针对的是接口

3.6 迪米特法则 | 最少知道原则（Demeter Principle）

类向外公开的方法应该尽可能的少
依赖的对象尽可能的少（只依赖必须依赖的对象）

4.设计模式的分类

创建型模式： 对象实例化的模式，创建型模式用于解耦对象的实例化过程

结构型模式： 把类或对象结合在一起形成一个更大的结构

行为型模式： 类和对象如何交互，及划分责任和算法

思维导图如下：

5. 个人总结

代码是个程序员就能敲出来，但是如何写出可复用、可维护、稳健、安全的代码设计，却不是那么容易的事情

最初听闻设计模式的时候感觉这种方式离自己还很遥远，觉得不好学，有种畏惧的心理

但是随着了解了设计模式的六大原则，一个模式一个模式的去了解分析，不断的尝试在代码中合适的场景中去代入设计模式相关的概念，发现其实也没自己之前想的那么难。关键就是要用心学，最初看着忘着很正常，毕竟使用了设计模式的代码理念，和原有敲代码的行为习惯冲突很大，关键是要坚持的学下去

在使用设计模式之前，一定要搞清楚你想要的使用的这个设计模式的作用域在哪，能够解决什么问题。另外提出一点我个人推崇的一句话：“纸上得来终觉浅，绝知此事要躬行”, 搁那看十遍网上的例子，普遍都是些猫啊、狗啊、汽车、车场啥的，不如经过深思熟虑在项目中实际应用一场，这样才能牢固记住这个设计模式的运用场景及优点

当然，会用设计模式和在适当的场景下使用是两码事。比如，你发现了项目代码中有一个很长的if else，你就想来点骚操作，用自己刚学的策略模式哐哐哐的优化。在这里，如果这个判断语句是可穷举的，用策略模式去优化就失去了策略模式该有的语义，也是架构师经常和我提及的一个点，就是不要 过度设计

最后要提的就是 学习设计模式没有捷径。 最终要达到的效果就是让设计模式的思想成为你开发技能的一部分，能够手到擒来，灵活运用。当然，这种效果不是你看一本书、看几篇博客、听别人口头上讲讲设计模式怎么怎么样就可以实现的，它需要不断沉淀与积累，在项目中合适的场景进行运用、总结。说来喝去就是一句话："对于设计模式的学习不要急于求成，要循序渐进"

希望通过这个 《设计模式》 专栏将自己所知、理解的设计模式通过博客文章的形式进行输出。专栏中博客皆为原创，如有错误之处希望各位大佬留言指正，不胜感激

《设计模式》专栏皆为作者原创，专栏中每一篇设计模式的讲解都是在项目中实际应用的。如果本专栏对你有用，欢迎点赞、关注、转载，由于作者水平有限，如有问题请留言。

微信搜索【源码兴趣圈】，关注龙台，回复【资料】领取涵盖 GO、Netty、SpringCLoud Alibaba、Seata、开发规范、面试宝典、数据结构等电子书 or 视频学习资料！