导语
面向对象的设计原则，他们就像面向对象程序设计中的金科玉律，遵守他们可以使我们的代码更加鲜活，易于复用，易于扩展，灵活优雅。不同的设计模式对应不同的需求，而设计原则则代表永恒的灵魂，需要在实践中时时刻刻地遵守。就如Arthur J.Riel在《OOD启示录》中所说的：“你并不必严格遵守这些原则，违背他们也不回被处以宗教刑罚。但你应当把这些原则看做警铃，若违背了其中的一条，那么警铃就会响起。”(该文章内容来源于本人的CSDN博客)
一、单一职责原则(Single-Responsibility Principle):
单一职责的含义是：类的职责单一，引起类变化的原因单一。解释一下，这也是灵活的前提，如果我们把类拆分成最小的职能单位，那组合与复用就简单的多了，如果一个类做的事情太多，在组合的时候，必然会产生不必要的方法出现，这实际上是一种污染。所谓职责，我们可以理解他为功能，就是设计的这个类功能应该只有一个，而不是两个或更多。也可以理解为引用变化的原因，当你发现有两个不同的变化会要求我们修改这个类，那么你就要考虑撤分这个类了。SRP优点：消除耦合，减小因需求变化引起代码僵化。
二、开闭原则(Open-Close Principal):
开闭原则的含义是：对扩展开放，对修改关闭。就是，我们写完的代码，不能因为需求变化就修改。我们可以通过新增代码的方式来解决变化的需求。当然，这是一种理想的状态，在现实中，我们要尽量的缩小这种修改。 再解释一下这条原则的意义所在，我们采用逆向思维方式来想。如果每次需求变动都去修改原有的代码，那原有的代码就存在被修改错误的风险，当然这其中存在有意和无意的修改，都会导致原有正常运行的功能失效的风险，这样很有可能会展开可怕的蝴蝶效应，使维护工作剧增。
三、里氏替换原则(Liskov-Substituion Principle)：
里氏替换原则的含义是：子类可以在任何地方替换它的父类。也就是说在程序中将基类替换为子类，程序的行为不会发生任何变化。 Liskov替换原则是关于继承机制的设计原则，违反了Liskov替换原则就必然导致违反开放封闭原则。 Liskov替换原则能够保证系统具有良好的拓展性，同时实现基于多态的抽象机制，能够减少代码冗余，避免运行期的类型判别。
四、依赖倒置原则（Dependecy-Inversion Principle）：
面相对象的初期的程序，被调用者依赖于调用者。也就是调用者决定被调用者有什么方法，有什么样的实现方式，这种结构在需求变更的时候，会付出很大的代价，甚至推翻重写。 依赖倒置原则就是要求调用者和被调用者都依赖抽象，这样两者没有直接的关联和接触，在变动的时候，一方的变动不会影响另一方的变动,面向抽象编程，解耦调用和被调用者。 具体而言就是高层模块不依赖于底层模块，二者都同依赖于抽象；抽象不依赖于具体，具体依赖于抽象。 我们知道，依赖一定会存在于类与类、模块与模块之间。当两个模块之间存在紧密的耦合关系时，最好的方法就是分离接口和实现：在依赖之间定义一个抽象的接口使得高层模块调用接口，而底层模块实现接口的定义，以此来有效控制耦合关系，达到依赖于抽象的设计目标。 依赖于抽象是一个通用的原则，而某些时候依赖于细节则是在所难免的，必须权衡在抽象和具体之间的取舍，方法不是一成不变的。依赖于抽象，就是对接口编程，不要对实现编程。
五、接口隔离原则(Interface-Segregation Principle):
它的含义是尽量使用职能单一的接口，而不使用职能复杂、全面的接口。 很好理解，接口是为了让子类实现的，如果子类想达到职能单一，那么接口也必须满足职能单一。 相反，如果接口融合了多个不相关的方法，那它的子类就被迫要实现所有方法，尽管有些方法是根本用不到的。这就是接口污染。
六、迪米特法则：
又叫作最少知道原则，迪米特原则要求尽量的封装，尽量的独立，尽量的使用低级别的访问修饰符。就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。这是封装特性的典型体现。 一个类如果暴露太多私用的方法和字段，会让调用者很茫然。并且会给类造成不必要的判断代码。所以，我们使用尽量低的访问修饰符，让外界不知道我们的内部。这也是面向对象的基本思路。这是迪米特原则的一个特性，无法了解类更多的私有信息。 迪米特原则要求类之间的直接联系尽量的少，两个类的访问，通过第三个中介类来实现。
七、组合/聚合复用原则：
组合/聚合复用原则的含义是，如果只是达到代码复用的目的，尽量使用组合与聚合，而不是继承。因为继承的耦合性更大，组合聚合只是引用其他的类的方法，而不会受引用的类的继承而改变血统。说白了就是我只用你的方法，但我们并不是同类。
