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