Java设计模式之六大设计原则

       设计模式之所以存在，是为了提高代码的可复用性，可拓展性，可维护性，灵活性。总之一句话就是为了让我们开发更方便，更简洁，更省事儿。这些设计模式都是遵循设计原则而存在，但是不一定每一种设计模式都同时满足六大设计原则。下面我们先来谈谈六大设计原则。

1. 开闭原则
   定义：一个软件实体，如类，模块，和方法应该对拓展开放，对修改关闭。
   也即是说在有新需求增加的时候，跟该类相关的新功能不要通过修改该类去实现，而是应该增加一个类，来实现该功能。具体的例子在后面的文章中讲到设计模式的时候，会提到。这儿一言半语也说不清楚。
    
2. 里氏代换原则
   定义一：如果对每一个类型T1的对象o1,都有类型为T2的对象O2，使得以T1定义的所有程序P，在所有对象O1都替换成O2时，程序P的行为没有发生改变，那么类型T2是T1的子类。
   通俗点讲：其实这一条是用于约束子类的，子类可以拓展父类的功能，但是不能修改父类的原有功能。其包含了以下四点：
   1.子类可以实现父类的抽象方法，但是不能覆盖父类的抽象方法。
   2.子类可以在有父类功能的情况下，增加自己特有的方法。
   3.子类重载父类的方法时，方法的形参要比父类的形参更宽松。
   4.子类的重载父类的方法时，返回值必须比父类的返回值更严格，也就是说，子类方法的返回值，必须是父类方法的返回值或者这个返回值的子类。
   描述：在不修改父类的情况下还不影响程序的行为。只有当子类替换掉父类，不用修改父类的情况下还不影响程序的行为，父类才能被多个类继承复用，进行新的行为拓展。如果子类替换掉父类之后，连父类最基本的行为都不存在了，那其他继承于父类的子类行为也就跟着不存在了，那需要改的代码就更多了，这与我们的期望背道而驰了。
3.  依赖倒转原则
   定义：高层模块不应该依赖底层模块，二者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象。
   意思是说要面向接口编程，不要面向实现编程。也可以说是不要用具体的类来解决问题，这样很容易导致类之间的耦合度，需要用接口的方式来弱化类之间的耦合度。其实这个定义是相对于传统的C，C++等面向过程的开发语言来说的，因为面向过程的传统开发模式中，都是上向下依赖。
4. 接口隔离原则
   定义一：客户端不应该实现它不需要的接口。
   定义二：类之间的依赖应该建立在最小的接口上
   这两种说法其实是殊途同归，最后的要求都是一样，意思是说接口尽量细化，里面不要有不需要的方法，不要一个接口做了多个义务逻辑。这儿可能有人会疑惑，那这不是跟单一职责原则一样了吗？其实不是：单一职责重点在职责，接口隔离重点在接口依赖的隔离。另外单一职责主要约束类，其次是方法和接口，主要针对实现的细节，而接口隔离针对的是接口，主要针对抽象，针对整个框架的搭建。
5. 迪米特法则
   迪米特法则又叫最少知道法则，是强调了弱化类之间的耦合，以便利于复用，一个类被修改不会对有关系的类造成影响。
   通俗的来说就是一个类对自己依赖的类知道的越少越好，不论这个类逻辑有多复杂，都尽量在自己内部完成，不会对依赖的类暴露太多的消息。
6. 单一职责原则
   不要存在多于一个让类发生变更的原因。如果一个类实现多个功能，有可能因为一个功能的变更导致其他功能出现问题。