[Professional ASP.NET Design Pattern 读书笔记系列] 01 成功应用的模式

问题解决方案的抽象模板称为设计模式。它是解决方案的蓝图，但是并不是解决方案本身。

2. 设计模式的起源是什么？

Design Pattern Bible设计模式圣经这本书的四个作者（GoF）将总结出来的23中设计模式分为3各组，包括：

1）创造模式：负责对象构造和引用的模式。

2）结构模式：处理对象之间关系以及这些对象如何构成更大对象的模式。

3）行为模式：处理对象之间通信，特别是处理对象的权责和算法的模式。

3. 通用的设计模式什么？

1. KISS keep it simple stupid 保持简单愚蠢：KISS原则就是要让程序简介Simple而不是过于简介Simiplistic

2. DRY Don't Repeat Yourself 不要重复：DRY原则就是不让程序重复。避免重复的原则，就是把系统对象有共性的地方统一抽象出来。

3. 告诉对象应该做什么，而不是问他能不能做：这个原则就是说，A对象调用B对象方法的时候，应该让A能够直接告诉B去做这件事儿，而不是A询问了B的状态之后再决定B能不能做。至于B能不能做，应该由B自己决定，而不是A来决定。

4. 不写多余代码 You Ain't Gonna Need it（YAGNI）：不要因为你试图实现什么功能就写多余的代码，否则多余的代码会越积累越多。

5. 不同重点的分离 Separation of Concerns SOC：SoC就是要把不一款软件分离成不同的特性和数据。这些特性包裹了独特的行为，而这些数据能够被不同的类所使用。

4. 什么是SOLID原则：

1. Single responsibility principle SRP 单一责任制原则：每个对象只有一个改变的原因，只负责一个功能。

2. Open-Closed原则：类对拓展是open的，但是对其内部结构的修改时Close的。因为易于拓展，可以派生更多的类；如果进行拓展的时候，一定要对类的内部结构进行修改，那么可能会导致其它已经派生的类的功能受到影响。

3. Liskov Substitution Principl SP原则：任何父类能做的事儿，子类都能做。

4. Interface Segragation Principle ISP原则：接口分离原则：即设计的接口所对应的一系列方法应该要具备单一的目的，而不是试图使用一个借口包含大量一个对象实现该接口之后无用的方法。

5. Dependency Inversion Principle DIP 依赖反转原则：类的设计应该是尽量让类的表述通过抽象类和接口来实现，而不是过度依靠类在内部对这种方法的实现。