设计模式系列: OOP（Object-Oriented Programming）设计六大设计原则

面向对象设计原则是OOPS(Object-Oriented Programming System，面向对象的程序设计系统)编程的核心，Java编程最基本的原则就是要追求高内聚和低耦合的解决方案和代码模块设计。查看Apache和Sun的开放源代码能帮助你发现其他Java设计原则在这些代码中的实际运用。六点设计原则如下：

一、Open Close Principle （开闭原则）

OCP(Open Close Principle)原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。简单的说就是，我们编写的编写的代码应该面向扩展开放，而尽量不要通过修改现有代码来拥抱需求变更。这里，代码可以指的是一个功能模块，类，或者方法。

public interface OpenClosePrinceple{
    void openExtention();
    void closeModification();
}

OCP是一个最抽象的接口，而其余的5大原则只是OCP的子类接口，他们一起定义了OOP世界的开发标准，常用的23中设计模式只能算作这6大原则的实现抽象类，我们如何实践这条原则？能用抽象类的别用具体类，能用接口的别用抽象类。总之我们要尽量面向接口编程。
但是开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层次模块的变化，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。 在业务规则改变的情况下高层模块必须有部分改变以适应新业务，改变要尽量的少，防止变化风险的扩散 。

二、Single Responsibility Principle（职责单一原则）

SRP（Single Responsibility Principle）原则: 应该有且只有一个原因引起类或者方法的变更。简单的说就是一个类或者一个方法值做一件事情。

public interface SingleResPrinciple extends OpenClosePrinceple {
    void singleTask();
}

比如Android中的ImageLoader，ImageLoader主要需要实现2个功能，下载图片，缓存图片。 比如，我们把所有的要显示的功能放在一个ImageLoader类中，假设下载要改方式呢？缓存要改策略呢？我们统统要改ImageLoader，我们如何保证修改某个功能的过程中另一个功能依旧完好，没被污染？拆分职责，使用ImageCache接口及其子类实现进行缓存，和ImageLoader建立关联，职责单一了，你再在每个单一的职责类里面去修改相关代码，这样就可以保证其他功能代码被污染的概率大大降低。

三、Liskov Substitution Principle （里氏替换原则）

LSP(Liskov Substitution Principle)：所有引用基类的地方必须能透明地使用其子类的对象

public interface LiskovSubPrinciple extends OpenClosePrinceple {
    void liskovSubstitutionPrinciple();
}

简单的说就是只要父类能出现的地方子类就可以出现，而且替换为子类也不产生任何异常错误，反之则不然。这主要体现在，我们经常使用抽象类/基类做为方法参数，具体使用哪个子类作为参数传入进去，由调用者决定。
LSP原则包含如下几个方面：
1、子类必须完全实现父类的方法
2、子类可以有自己属性和方法
3、覆盖或者实现父类方法时，参数可以被放大。即父类的某个方法参数为ArrayList时，子类参数可以是List。
4、覆盖或者实现父类的方法时，返回结果可以被缩小。即父类的某个方法返回类型是List，子类可以是ArrayList。

四、Dependence Inversion Principle（依赖倒置原则）

DIP（Dependence Inversion Principle）原则：高层模块不要依赖低层模块，所以依赖都应该是抽象的，抽象不应该依赖于具体细节而，具体细节应该依赖于抽象，应该面向接口编程
底层模块就是不可分割的原子逻辑， 高层模块就是低层模块的组装合成后后的模块
DIP原则包含如下几个方面：
1、模块间的依赖应该通过抽象发生，具体实现类之间不应该建立依赖关系
2、接口或者抽象类不依赖于实现类，否则就失去了抽象的意义
3、实现类依赖于接口或者抽象类

五、Interface-Segregation Principle（接口隔离原则）

ISP（Interface-Segregation Principle）原则: 客户端不应该依赖它不需要的接口；类间的依赖应该建立在最小的接口上
简单的理解为：使用接口时应该建立单一接口，不要建立臃肿庞大的接口，尽量给调用者提供专门的接口，而非多功能接口。
例如Android中的事件处理Listener设计，我们想给View添加点击事件时，可以使用如下代码view.setOnClickListener(clickListener);
想给它添加长按事件时，可以使用如下代码view.setOnLongClickListener(longClickListener);
这就是遵循了ISP原则的结果，每个接口最小化了，View 作为调用者，我可以选择性的处理的事件，不关心的事件Listener不去处理，依赖。

六、Low of Demeter（迪米特法则）

LoD（Low of Demeter）法则：又称最少知识原则（Least Knowledge Principle， LKP），一个对象应该对其他对象有最少的了解。
可简单理解为：一个类应该对自己需要耦合或者调用的类知道越少越好，被耦合或者调用的类内部和我没有关系，不需要的东西你就别public了。
迪米特法则包含如下要素：
1、只和朋友类交流：只耦合该耦合的类
2、朋友间也是有距离的：减少不该public的方法，向外提供一个简洁的访问
3、自己的方法就自己创建：只要该方法不会增加内部的负担，也不会增加类间耦合