看设计模式有段时间了
，但是有没有多少机会使用。结果陷入到了“看了忘忘了再看”的恶性循环，
虽然我们本来就应该温故知新的。我们能不能找到一些更好的方法呢？
有一种叫做“自顶向下”的思路我们都很熟悉的可以拿来试试。
设计的原则
要学设计模式，设计的原则就不得不学。这里只做简单的介绍。需要更加详细的说明可以参考吕震宇的博客，非常的不错！
1. 单一职责原则（ The Single-Responsibility Principle ）
一个类只有一个引起变化的原因。可以想象，如果一个类承担了一个 以上的职责，
那么任何一个职责的变换都会影响到这个类所承担的其他职责。这是一种紧耦合的设计。
2.开放封闭原则（ The Open/Closed Principle ）
一个软件实体（类，模块，函数等）应该对扩展开放，而对修改封闭。
那么怎么才能做到这一点呢？关键是抽象。当模块依赖于和一个固定的抽象体时，它对更改时封闭的，
而它可以通过派生新类扩展模块的行为。
3.里氏替换原则（ The Liskov Substitution Principle ）
子类型必须能够替换他们的基类型
4.依赖倒置原则（ The Dependency-Inversion Principle）
a.高层模块不应该依赖于低层模块,二者都应该依赖于抽象.
b.抽象不应该依赖于细节。细节应该依赖于抽象。
从代码重用的角度讲，我们更希望重用的是高层的抽象出来的模块。当高层模块依赖于低层模块的时候，
在不同的环境对高层模块使用的也会受到很大的制约。
“Don't call us，we'll call you。”用低层模块实现高层模块中的声明并被高层模块调用的接口。
5.接口分离原则（The Interface Segregation Principle）
过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：
一个类对另外一个类的依赖性应当是建立在最小接口上的。
补充：我们还需要搞清楚IS-A和HAS-A。
"Is-A"是严格的分类学意义上定义，意思是一个类是另一个类的"一种"。而"Has-A"则不同，
它表示某一个角色具有某一项责任。
模式是如何组织的
模式的组织模式有很多种。网上很多文章会直接把设计模式分为创建型模式，结构型模式，行为型模式 ，
所以我们主要讨论这些模式的分类方式。
分类的理由何在？两个标准：一个是目的，一个是范围。
根据目的模式可以分为，创建模式、结构模式和行为模式，也就是我们上面提到的。创建型模式关心对象的创建过程，
结构型模式涉及的是类和对象的组成，行为模式描述的是类和对象的交互以及职责分配的方式。
第二个标准，称为范围（Scope）。范围描述了模式主要是应用于对象，
还是主要应用于类。“类模式”主要处理类与其子类的关系，这种关系是通过继承得来的，因此它们是静态-固定、由编译时决定的；
“对象模式”处理对象关系，这种关系是运行时决定的，是动态关系。几乎所有的模式都在某种程度上使用了继承，
因此只有那些标明为“类模式”的模式才重点关注类关系， 大多数模式都在“对象模式”范畴。
“创建性类模式”将部分的对象创建工作延迟到了子类， 而“创建性对象模式”将其延迟到了另外的对象。
“结构性类模式”应用继承机制来合成类， 而“结构性对象模式”则规定了装配对象的方式。
行为性类模式用继承机制来描述算法和控制流， 而行为性对象模式则规定一组对象如何合作以完成某项单一对象 不能达成的任务
参考：
http://blogger.org.cn/blog/more.asp?name=torrent&id=6725
http://www.cnblogs.com/zhenyulu/category/6930.html?Show=All
Agile Principles, Patterns, and Practices in C# author: Martin C. Robert, Martin Micah
虽然我们本来就应该温故知新的。我们能不能找到一些更好的方法呢？
有一种叫做“自顶向下”的思路我们都很熟悉的可以拿来试试。
设计的原则
要学设计模式，设计的原则就不得不学。这里只做简单的介绍。需要更加详细的说明可以参考吕震宇的博客，非常的不错！
1. 单一职责原则（ The Single-Responsibility Principle ）
一个类只有一个引起变化的原因。可以想象，如果一个类承担了一个 以上的职责，
那么任何一个职责的变换都会影响到这个类所承担的其他职责。这是一种紧耦合的设计。
2.开放封闭原则（ The Open/Closed Principle ）
一个软件实体（类，模块，函数等）应该对扩展开放，而对修改封闭。
那么怎么才能做到这一点呢？关键是抽象。当模块依赖于和一个固定的抽象体时，它对更改时封闭的，
而它可以通过派生新类扩展模块的行为。
3.里氏替换原则（ The Liskov Substitution Principle ）
子类型必须能够替换他们的基类型
4.依赖倒置原则（ The Dependency-Inversion Principle）
a.高层模块不应该依赖于低层模块,二者都应该依赖于抽象.
b.抽象不应该依赖于细节。细节应该依赖于抽象。
从代码重用的角度讲，我们更希望重用的是高层的抽象出来的模块。当高层模块依赖于低层模块的时候，
在不同的环境对高层模块使用的也会受到很大的制约。
“Don't call us，we'll call you。”用低层模块实现高层模块中的声明并被高层模块调用的接口。
5.接口分离原则（The Interface Segregation Principle）
过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：
一个类对另外一个类的依赖性应当是建立在最小接口上的。
补充：我们还需要搞清楚IS-A和HAS-A。
"Is-A"是严格的分类学意义上定义，意思是一个类是另一个类的"一种"。而"Has-A"则不同，
它表示某一个角色具有某一项责任。
模式是如何组织的
模式的组织模式有很多种。网上很多文章会直接把设计模式分为创建型模式，结构型模式，行为型模式 ，
所以我们主要讨论这些模式的分类方式。
分类的理由何在？两个标准：一个是目的，一个是范围。
根据目的模式可以分为，创建模式、结构模式和行为模式，也就是我们上面提到的。创建型模式关心对象的创建过程，
结构型模式涉及的是类和对象的组成，行为模式描述的是类和对象的交互以及职责分配的方式。
第二个标准，称为范围（Scope）。范围描述了模式主要是应用于对象，
还是主要应用于类。“类模式”主要处理类与其子类的关系，这种关系是通过继承得来的，因此它们是静态-固定、由编译时决定的；
“对象模式”处理对象关系，这种关系是运行时决定的，是动态关系。几乎所有的模式都在某种程度上使用了继承，
因此只有那些标明为“类模式”的模式才重点关注类关系， 大多数模式都在“对象模式”范畴。
“创建性类模式”将部分的对象创建工作延迟到了子类， 而“创建性对象模式”将其延迟到了另外的对象。
“结构性类模式”应用继承机制来合成类， 而“结构性对象模式”则规定了装配对象的方式。
行为性类模式用继承机制来描述算法和控制流， 而行为性对象模式则规定一组对象如何合作以完成某项单一对象 不能达成的任务
参考：
http://blogger.org.cn/blog/more.asp?name=torrent&id=6725
http://www.cnblogs.com/zhenyulu/category/6930.html?Show=All
Agile Principles, Patterns, and Practices in C# author: Martin C. Robert, Martin Micah
欢迎加群互相学习，共同进步。QQ群：iOS: 58099570 | Android: 330987132 | Go：217696290 | Python：336880185 | 做人要厚道，转载请注明出处！
