包括7大设计原则和23大设计模式。
7大设计原则
这7大设计原则不仅是23大设计模式要去遵守的，也是我们平常开发过程中要时刻去遵守的准则，所以说非常非常重要。
1，单一职责原则
1）定义：就一个类而言，应该仅有一个引起它变化的原因。简而言之，就是功能要单一。
2）如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。(敏捷软件开发)。
3）软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
4）单一职责原则可以看做是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。责任过多，引起它变化的原因就越多，这样就会导致职责依赖，大大损伤其内聚性和耦合度。
2，开放关闭原则
1）定义：就是说软件实体(类，方法等等)应该可以扩展（扩展可以理解为增加），但是不能在原来的方法或者类上修改，也可以这样说，对增加代码开放，对修改代码关闭。
2）两个特征： 对于扩展（增加）是开放的，因为它不影响原来的，这是新增加的。对于修改是封闭的，如果总是修改，逻辑会越来越复杂。
3）开放封闭原则是面向对象设计的核心思想。遵循这个原则可以为我们面向对象的设计带来巨大的好处：可维护（维护成本小，做管理简单，影响最小）、可扩展（有新需求，增加就好）、可复用（不耦合，可以使用以前代码）、灵活性好（维护方便、简单）。开发人员应该仅对程序中出现频繁变化的那些部分做出抽象，但是不能过激，对应用程序中的每个部分都刻意地进行抽象同样也不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。
3，里氏代替原则
1）定义：子类型必须能够替换掉它们的父类型。更直白的说，里氏代替原则是实现面向接口编程的基础。
2）任何基类可以出现的地方，子类一定可以出现，所以我们可以实现面向接口编程。 里氏代替原则是继承复用的基石，只有当子类可以替换掉基类，软件的功能不受到影响时，基类才能真正被复用，而子类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
4，依赖倒置原则
1）定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。简单说就是，我们要针对接口编程，而不要针对实现编程。
2）高层模块不应该依赖低层模块，两个都应该依赖抽象，因为抽象是稳定的。抽象不应该依赖具体（细节），具体（细节）应该依赖抽象。
3）依赖倒置原则其实可以说是面向对象设计的标志，如果在我们编码的时候考虑的是面向接口编程，而不是简单的功能实现，体现了抽象的稳定性，只有这样才符合面向对象的设计。
5，接口隔离原则
1）定义：指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责，而应把每个职责分离到多个专门的接口中，进行接口分离。过于臃肿的接口是对接口的一种污染。
2）使用多个专门的接口比使用单一的总接口要好。
3）一个类对另外一个类的依赖性应当是建立在最小的接口上的。
4）一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。
5）不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。
6）接口隔离原则告诉我们，在做接口设计的时候，要尽量设计的接口功能单一，功能单一，使它变化的因素就少，这样就更稳定，其实这体现了高内聚，低耦合的原则，这样做也避免接口的污染。
6，组合复用原则
1）定义：就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说，就是要尽量使用合成/聚合，尽量不要使用继承。
2）要使用好组合复用原则，首先需要区分”Has—A”和“Is—A”的关系。 “Is—A”是指一个类是另一个类的“一种”，是属于的关系，而“Has—A”则不同，它表示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“Has—A”当成“Is—A”.例如：鸡是动物，这就是“Is-A”的表现，某人有一个手枪，People类型里面包含一个Gun类型，这就是“Has-A”的表现。
3）组合/聚合复用原则可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，需要严格遵循里氏替换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
7，迪米特法则
1）定义：迪米特法则又叫最少知识原则（Least Knowledge Principle，LKP），指的是一个对象应当对其他对象有尽可能少的了解。也就是说，一个模块或对象应尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立，这样当一个模块修改时，影响的模块就会越少，扩展起来更加容易。
2）关于迪米特法则其他的一些表述有：只与你直接的朋友们通信；不要跟“陌生人”说话。
3）外观模式（Facade Pattern)和中介者模式（Mediator Pattern）就使用了迪米特法则。
4）迪米特法则的初衷是降低类之间的耦合，实现类型之间的高内聚，低耦合，这样可以解耦。但是凡事都有度，过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。
创建型
创建型设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
创建型设计模式包括以下5种：
设计模式系列1：单例模式（Singleton Pattern）
设计模式系列2：工厂方法模式（Factory Method Pattern）
设计模式系列3：抽象工厂模式（Abstract Factory Pattern）
设计模式系列4：建造者模式（Builder Pattern）
设计模式系列5：原型模式（Prototype Pattern）
结构型
结构型设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
结构型设计模式包括以下7种：
设计模式系列6：适配器模式（Adapter Pattern）
设计模式系列7：桥接模式（Bridge Pattern）
设计模式系列8：装饰模式（Decorator Pattern）
设计模式系列9：组合模式（Composite Pattern）
设计模式系列10：外观模式（Facade Pattern）
设计模式系列11：享元模式（Flyweight Pattern）
设计模式系列12：代理模式（Proxy Pattern）
行为型
行为型设计模式主要讨论的是在不同对象之间划分责任和算法的抽象化的问题。
行为型设计模式包括以下11种：
设计模式系列13：模板方法模式（Template Method Pattern）
设计模式系列14：命令模式（Command Pattern）
设计模式系列15：迭代器模式（Iterator Pattern）
设计模式系列16：观察者模式（Observer Pattern）
设计模式系列17：中介者模式（Mediator Pattern）
设计模式系列18：状态模式（State Pattern）
设计模式系列19：策略模式（Stragety Pattern）
设计模式系列20：责任链模式（Chain of Resp Pattern）
设计模式系列21：访问者模式（Vistor Pattern）
设计模式系列22：备忘录模式（Memento Pattern）
设计模式系列23：解释器模式（Interpreter Pattern）
参考资料
- https://www.dofactory.com/net/design-patterns
- http://www.runoob.com/design-pattern/design-pattern-tutorial.html
- https://www.cnblogs.com/PatrickLiu/p/8287784.html
- https://www.cnblogs.com/abcdwxc/archive/2007/10/30/942834.html
源代码
Github地址：https://github.com/mcgrady525/GettingStarted.DesignPattern
