1、单一职责原则

单一职责原则是指,不要让一个类承担过多的职责。避免职责耦合在一起,避免一个职责的变化影响到其他职责。

比如在Activity中存在网络请求的逻辑,导致Activity过于臃肿,导致引起这个Activity变化的原因太多,这样就违反了单一职责原则,不利于后续的版本维护。

最后再来理解一下单一职责的定义——就一个类而言,应该仅有一个引起它变化的原因。

2、开放封闭原则

在开发过程中,需求的变化如果要通过修改原有的代码来完成,那么就很可能将新的错误引入到旧的代码中。因此才有了开放封闭原则。就是说,需求改变时,我们应该尽量通过拓展的方式、即加入新代码来实现变化。

比如我们要实现一个银行业务的逻辑,如下所示:

//By SEU_Calvin on 2017/03/27
public class BankProcess {
public void Deposite() {//存款
}
public void Withdraw(){//取款
}
}

public class BankStaff {
private BankProcess bankpro = new BankProcess();
public void BankHandle(Client client) {
switch (client.Type) {
case "deposite": // 存款
bankpro.Deposite();
break;
case "withdraw": // 取款
bankpro.Withdraw();
break;
}
}
}

这样直接调用BankStaff.BankHandle()方法,通过传入的参数完成对应的存取款功能。

但是这时加入了转账业务呢,就需要去修改BankProcess类,这样既违反了单一职责原则,也违反了我们的开放封闭原则,因为BankProcess职责不单一,且新需求需要修改已有的代码。因此可以使用的接口的方式进行优化:

//By SEU_Calvin on 2017/03/27
public interface IBankProcess {
void Process();
}

public class DeposiProcess implements IBankProcess {
public void Process(){ // 办理存款业务
}
}

public class WithDrawProcess implements IBankProcess{
public void Process(){ // 办理取款业务
}
}

public class TransferProcess implements IBankProcess{
public void Process(){ //办理转账业务
}
}

public class BankStaff {
private IBankProcess bankpro = null;

public void BankHandle(Client client) {
switch (client.Type) {
case "Deposite": // 存款
bankpro = new DeposiProcess();
break;
case "WithDraw": // 取款
bankpro = new WithDrawProcess();
break;
case "Transfer": // 转账
bankpro = new TransferProcess();
break;
}
bankpro.Process();
}
}

这样如果我们再添加功能,你会发现我们不需要修改原有的类,只需要添加一个功能类的子类即可。

最后再来理解一下开放封闭的定义——软件中的对象(类、模块、函数等)应该对于拓展是开放的,而对于修改是封闭的。

3、里氏替换原则

里氏代换原则告诉我们,只要父类出现的地方,子类就可以出现,替换为子类后不会产生任何错误和异常,当然反过来未必适应。

我们在运用里氏代换原则时,尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法,在运行时再确定其子类类型,用子类实例来替换父类实例。如2的例子中对bankpro的实例化。就可以很方便地扩展系统的功能,同时无须修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。因此说,里氏替换原则是开闭原则的具体实现手段之一。

最后再来理解一下里氏替换原则的定义——所有引用基类(父类)的地方必须能透明地使用其子类的对象

4、依赖倒置原则

依赖倒置原则在Java中是指接口或抽象类不依赖于实现类,而实现类依赖接口或抽象类。

就是说如果类与类直接依赖细节,那么就会直接耦合,那么当修改时,就会同时修改依赖者代码,这样限制了可扩展性。依赖倒置就是为了解决耦合。让程序依赖于抽象。

//By SEU_Calvin on 2017/03/27
public class Fute {
public void run() {
System.out.println("福特汽车启动");
}

public void stop() {
System.out.println("福特汽车停止");
}
}

public class Bentian {
public void run() {
System.out.println("本田汽车启动");
}

public void stop() {
System.out.println("本田汽车停止");
}
}

public class AtuoRunSystem {

private String mType;
private Bentian bentian = new Bentian();
private Fute fute = new Fute();

public AtuoRunSystem(String type) {
mType = type;
}

public void AutoRun() {
if ("bentian".equals(mType)) {
bentian.run();
} else {
fute.run();
}
}

public void AutoStop() {
if ("bentian".equals(mType)) {
bentian.stop();
} else {
fute.stop();
}
}
}

代码很简单,但是缺点也很明显,扩展性特别差,现在只有两种车,if-else语句还算简单,假设以后有100种车…

//By SEU_Calvin on 2017/03/27
public interface Icar {
void run();
void stop();
}

public class Fute implements Icar {

public void run() {
System.out.println("福特汽车启动");

}

public void stop() {
System.out.println("福特汽车停止");

}

}

public class Bentian implements Icar {

@Override
public void run() {
System.out.println("本田汽车启动");

}

@Override
public void stop() {
System.out.println("本田汽车停止");

}

}

public class AtuoRunSystem {

private Icar icar;

public AtuoRunSystem(Icar icar) {
this.icar = icar;
}

public void autoRun() {
icar.run();

}

public void autoStop() {
icar.stop();
}

}

经过改造,再加入新车我们也不怕了。这种设计也充分说明了,类与类不应该直接依赖细节,因为这样会导致耦合,限制了可扩展性,而是让类与类直接依赖抽象。

5、迪米特原则

也称为最少知识原则,是指一个对象应该对其他对象有最少的了解。

通俗的讲,一个类对自己需要耦合的类应该知道的最少,你内部多么复杂和我没关系,我只对你提供的public方法感兴趣。这样的话,如果一个系统符合迪米特法则,那么当其中某一个类发生修改时,就会尽量少地影响其他模块,降低系统的耦合度,使类与类之间保持松散的耦合关系。

下面是老师让班长清点班级人数的例子:

//By SEU_Calvin on 2017/03/27
public class Teacher {
public void commond(Monitor monitor) {
List<Student> lists = new ArrayList();
// 初始化同学
for (int i = 0; i < 20; i++) {
lists.add(new Student());
}
// 告诉班长清点人数
monitor.count(lists);
}
}

public class Monitor {
// 有清查女生的工作
public void count(List<Student> lists) {
System.out.println(lists.size());
}
}

//调用时
Teacher teacher= new Teacher();
teacher.commond(new

我们看到Teacher类不仅与Monitor类产生了关系,还和Student类产生了关系。产生了不必要的耦合。这样Student类的变化不仅影响Monitor类,还会影响到Teacher类。程序优化修改后如下,调用方法不变:

//By SEU_Calvin on 2017/03/27
public class Teacher {
public void commond(Monitor monitor) {
monitor.count();
}
}

public class Monitor {
public void count() {
List<Student> lists = new ArrayList();
for (int i = 0; i < 20; i++) {
lists.add(new Student());
}
System.out.println(lists.size());
}
}

//调用时
Teacher teacher= new Teacher();
teacher.commond(new

6、接口隔离原则

接口隔离原则的含义是:建立单一接口而不是建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

比如说,定义了一个接口MyInterface。

public interface MyInterface{
public void method1();
public void method2();
public void method3();
}

但是实现类A只想实现接口中的method1方法,而实现类B只想实现接口中的method2、method3方法。

此时只写一个接口让A、B都去实现该接口的话,会导致AB中会实现不需要的方法,这样设计接口会导致接口比较臃肿,因此我们应该要把这个接口拆分开来写。

很多人会觉的接口隔离原则跟之前的单一职责原则很相似,其实不然。单一职责原则注重的是职责,针对的是程序中的实现和细节;而接口隔离原则注重的是对接口依赖的隔离,主要针对抽象。

最后理解一下接口隔离原则的定义:类间的依赖应该建立在最小的接口上。