1.偏头痛杨的常见设计模式入门系列之什么是设计模式篇

前戏

总听到大家会谈论设计模式，会不会是什么很高端的概念呢？其实并没有。

随着大家水平的深入，以及不断的自我挑战，自我驱动，

大家慢慢会成长到需要看一些优秀项目源码的阶段（例如：spring、dubbo、rocketmq等），

那如果我们不掌握一些设计模式理论的话，看的真是云里雾里，完全不懂那些优秀源码为什么要那么写，

那么写的好处是什么，也无法通过源码来提升自己的代码能力。

因此，熟悉&理解设计模式就显得非常重要了，并且在我们日常开发中，也可以去运用设计模式，利人利己。

---

什么是设计模式

日常开发中，我们经常会面对各种各样的问题，而这些问题往往具有特定的触发条件&环境&机制，

而且会经常出现，此时我们通过前辈总结出的成熟解决方案来解决问题，可提升应用开发的效率&质量。

这些成熟的解决方案就是设计模式。

日常生活中到处都有模式的场景，例如在开车时看到了红灯，第一反应是踩刹车，

这是一种惯性思维，不用动脑子去想。

通过设计模式就可以直接运用前辈的经验，避免重复设计。

学习设计模式之前，必须要积累足够多的代码量，刚入行就开始看设计模式，有点本末倒置，得不偿失。

---

常见的设计原则

设计模式中往往都或多或少的在使用设计原则，学习设计模式之前，需要先了解一些常见的设计原则。

先有的设计原则， 再有设计模式。

• OCP原则（开放关闭原则，Open Closed Principle）

对扩展开放，对修改关闭。

在许多复杂逻辑都写在一个类的情况下，不停的在原来的类中进行修改，

会有造成改出其他bug的隐患（非本逻辑的bug，因为逻辑没有隔离），

并且作为让某个程序员做修改代码时，不想让他看到之前老的核心代码，怎么办？如何做风控？

那么我们需要使用继承、多态等形式来进行扩展，这样在添加&修改代码时，不会影响到其他代码，

其他代码就不用去测试了，因为没有改动过，不会产生新的bug。

当然，如果类本身就很简单，就没必要去用开放关闭原则了，大胆的去改吧。

• SRP原则（单一职责原则，Single Responsibility Principle）

对于一个类而言，应该仅有一个引起它变化的原因。

不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。

当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？

如果真的有必要，那就分吧。千万不要让一个类干的事情太多！

• HP原则（好莱坞原则，Hollywood Principle）

好莱坞明星的经纪人一般都很忙，他们不想被打扰，往往会说：Don't call me, I'll call you.

不要联系我，我会联系你。对应于软件设计而言，最著名的就是“控制反转”（或称为“依赖注入”），

我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象。

• COC原则（约定大于配置，Convention over Configuration）

尽量让约定来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。

例如：大家都是这么做的，已经成为习惯了，那就没必要再让大家配置一遍了，看看springboot吧。

• KISS原则（简单傻瓜，Keep it simple and stupid）

尽量的简单与傻瓜， 不要让程序变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。

• DRY原则（不要重复你自己，Don't repeat yourself）

不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装，重复的就是丑陋的。

新手玩家一般最喜欢cv工程（ctrl+c&ctrl+v），但这样非常不好，修改的时候就痛了。

• CQS原则（命令查询分离，（Command Query Separation）

在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。

• YAGNI原则（你不需要它，You aren't gonna need it）

不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的简单，而却又不失扩展性。

• HCLC原则（高内聚与低耦合，High Cohesion and Low Coupling）

模块内部需要做到内聚度高，隐含内部细节（内部数据&方法的实现细节独立完成并隐藏掉）。

模块之间需要做到耦合度低，彼此相互隔离（尽量少暴露方法给外部使用，大量的内部实现细节不允许外部干涉）。

• ISP原则（接口隔离原则，Interface Segregation Principle）

一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。

不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性。

---

设计模式的分类

我们可以把23种设计模式分为三大类，有助于我们结构化的记忆与理解。

• 创建型

创建对象时，不再由我们直接实例化对象，而是根据特定的场景，由程序来确定创建对象的方式， 从而保证更大的性能，

更好的架构优势。

~工厂模式（简单工厂，工厂方法，抽象工厂）

~单例模式

~生成器模式

~原型模式

• 结构型

用于帮助将多个对象组织成更大的结构。

~适配器模式

~桥接模式

~组合器模式

~装饰器模式

~门面模式

~享元模式

~代理模式

• 行为型

用于帮助系统间各对象的通信，以及如何控制复杂系统中的流程。

~命令模式

~解释器模式

~迭代器模式

~中介者模式

~备忘录模式

~观察者模式

~状态模式

~策略模式

~模版模式

~访问者模式

---

总结

后续的文章会逐步介绍这些设计模式，希望大家以理解为主，切忌不要死记硬背。

2.偏头痛杨的常见设计模式入门系列之单例模式篇

http://blog.csdn.net/piantoutongyang/article/details/78318306

3.偏头痛杨的常见设计模式入门系列之工厂模式篇（简单+方法+抽象）

http://blog.csdn.net/piantoutongyang/article/details/78344472

4.偏头痛杨的常见设计模式入门系列之代理模式篇

http://blog.csdn.net/piantoutongyang/article/details/78344488

5.偏头痛杨的常见设计模式入门系列之观察者模式篇

http://blog.csdn.net/piantoutongyang/article/details/78344514

6.偏头痛杨的常见设计模式入门系列之命令模式篇

http://blog.csdn.net/piantoutongyang/article/details/78344546

7.偏头痛杨的常见设计模式入门系列之门面模式篇

http://blog.csdn.net/piantoutongyang/article/details/78344552