设计模式的主要设计原则简介

1.单一职责原则（SRP）

“单一职责模式”按照字面理解就是，一个类的功能要“单一”或者专一，不能武断地把很多相关或者不相关的功能强制写进一个类里去，它的准确解释是：“就一个类，应该仅有一个引起它变化的原因”。我个人认为这个原则主要就是教我们如何抽象并“封装”类。
举例：对于初学者来说，我们几乎都写过的代码，如webform和winform下用户进行登陆，webform的default.aspx.cs类和winform的form1.cs不用写一样的具体登陆业务逻辑，如数据库连接和查询，登陆账户和密码的匹配等等，而是应该抽象出用户类和一个登陆方法，然后winform或者webform共同调用该类的登陆方法就可以了。

2.开放-封闭原则（OC）

“对于扩展开放，对于更改封闭。”也就是“面对需求，对程序的改动是通过增加代码进行的，而不是更改现有的代码”。对于随时可能变化的需求，这个原则对于开发者而言实在是太重要了。在设计的时候，我们要尽量考虑种种变化，把问题考虑的尽量全面一些。但是，无论考虑的多么周到，无论你设计的模块多么“封闭”，都会存在一些无法对之封闭的变化。既然不太可能完全封闭，我们就必须对设计模块进行抽象，分离出变化点，以备将来“扩展”。我们都希望在开发工作展开之前或者开始不久就知道项目中可能的变化，这样遵循这个原则，抽象出变化点，程序的“可维护，可扩展，可复用和灵活性好”将大大增强。
举例：写计算器程序是一个经典的例子，开始要求写个加法运算，很快我们在客户端client写了出来。这个时候又要求写个减法运算，我们不得不更改client的类，这就违背了“对更改封闭”，所以我们最好抽象出一个抽象的运算类Operation，通过面向对象常见的继承和多态等特征来隔离具体加减乘除等方法与client的耦合，这样需求依然可以满足，还能应对变化。
3.里氏代换原则（LSP）
简单地说，也就是“子类型必须能够替换掉它们的父类型”。一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。在程序中，把父类都替换成它的子类，程序的行为没有变化。
举例：在编程时，我们设计出一个鱼类（Fish），它的行为是”游“（Swim），接着是“金鱼（GoldFish）和木鱼（WoodenFish）”类，都继承鱼类，但是我们看到金鱼很显然可以“游”，但是木鱼只能被敲打而不能”游“，也就是说木鱼类不能继承鱼类。（这个例子也许不合适，听歌的时候想到的）
4.依赖倒转原则（DIP）

在解释这个原则前，我们先看看经常碰到的“依赖”，也就是耦合,耦合可以分为下面三种 ：
（1）零耦合(Nil Coupling)关系,两个类没有依赖关系,那就是零耦合.
（2）具体耦合(Concrete Coupling)关系,两个具体的类之间有依赖关系,那么就是具体耦合关系,如果一个具体类直接引用另外一个具体类,就会发生这种关系.
（3）抽象耦合(Abstract Coupling)关系.这种关系发生在一个具体类和一个抽象类之间,这样就使必须发生关系的类之间保持最大的灵活性. （这也正是我们编程过程中最期望的耦合方式）
最经典最完美解释：“要针对接口编程，不要针对实现编程”。
依赖倒转原则：（1）高层模块不应该依赖底层模块。两个都应该依赖抽象。（2）抽象不应该依赖细节，细节应该依赖于抽象(Abstractions should not depend upon details. Details should depend upon abstractions)。“抽象”通常都是接口或者抽象类。这里重点是用到了面向对象里的“继承”特性。必须要注意：这个原则前提是里氏代换原则，在程序中，把父类替换成子类，程序的行为不会发生变化。只有当子类可以完全替换掉父类，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
举例：还以webform的用户登陆为例，用户按照类别可以分成多种类型，比如普通注册用户，公司员工，不同等级的忠实用户，vip用户等等。我们抽象出一个抽象类User，这样让不同类别的员工继承User，普通用户和公司员工可能只有抽象类里的登陆方法，而不同等级的忠实用户和vip用户有扩展出一些自己独有的行为，如支付等等。这样通过父类User，要调用一个不同类别的用户就可以通过父类变量等于new一下具体类别的用户类就可以了。

5.迪米特法则（LoD）
又叫最少知识原则（Least Knowledge Principle 简写LKP）就是说，一个对象应当对其它对象有尽可能少的了解，也叫做“不要和陌生人说话”。它的正确解释是”如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。“。它强调我们在封装类的时候，在类的设计结构上，每一个类都应当降低成员的访问权限。类与类之间的耦合度越低越好，因为一个类被修改，不会对有关联的其他类也进行修改。