0
点赞
收藏
分享

微信扫一扫

Java开发(七)大设计原则

目录

​​一、开闭原则(Open Closed Principle,OCP)​​

​​内涵​​

​​益处​​

​​实现方式​​

​​二、里氏替换原则(Liskov Substitution Principle,LSP)​​

​​内涵​​

​​益处​​

​​实现方式​​

​​三、依赖倒置原则(Dependence Inversion Principle,DIP)​​

​​内涵​​

​​益处​​

​​实现方式​​

​​四、单一职责原则(Single Responsibility Principle,SRP)​​

​​内涵​​

​​益处​​

​​实现方式 ​​

​​五、接口隔离原则(Interface Segregation Principle,ISP)​​

​​内涵​​

​​益处​​

​​实现方式 ​​

​​六、迪米特法则(Law of Demeter,LoD)​​

​​内涵​​

​​益处​​

​​实现方式 ​​

​​ 七、合成复用原则(Composite Reuse Principle,CRP)​​

​​内涵​​

​​益处​​

​​实现方式 ​​

​​总结​​

 Java开发里面最核心的目标是“强内聚,弱耦合”,在这个核心目标下才产生了下面要介绍的7种原则,换句话说,这7种原则都是为了实现“强内聚弱耦合”的目标,在这7种原则往下又派生出23种设计模式(代理/策略/观察者...等),各种设计模式往下又派生出各种框架(Spring/SpringMVC...等),后面在一一介绍,这里先介绍7种原则。

一、开闭原则(Open Closed Principle,OCP)

内涵

对修改关闭,对扩展开放。当应用的需求改变时,在不修改软件实体的源代码或者二进制代码的前提下,可以扩展模块的功能,使其满足新的需求。

益处

  1. 可以提高代码的可复用性:粒度越小,被复用的可能性就越大;
  2. 可以提高软件的可维护性:遵守开闭原则的软件,其稳定性高和延续性强,从而易于扩展和维护;
  3. 易于测试:遵守开闭原则,测试时只要对扩展的代码进行测试就可以了,因为原有代码仍然能够正常运行


实现方式

通过接口或者抽象类定义一个相对稳定的抽象层,而将相同的可变因素封装在具体实现类中。

因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展,当软件需要发生变化时,只需要根据需求重新派生一个实现类来扩展就可以了。

二、里氏替换原则(Liskov Substitution Principle,LSP)

内涵

继承必须确保超类所拥有的性质在子类中仍然成立。换句话说,父类出现的地方,都可以用子类替换。

益处

类的扩展不会给已有的系统引入新的错误,降低了代码出错的可能性。

只有子类可以替换掉父类,系统还不受影响,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为。

实现方式

里氏替换原则通俗来讲就是:子类可以扩展父类的功能,但不要改变父类原有的功能。

也就是说:子类继承父类时,除添加新的方法完成新增功能外,尽量不要重写父类的方法(用重写了父类方法的子类去替换父类,在遇到这个重写方法时执行的就是子类重写的这个而不是父类的,也就是说破坏了原来的功能)。

当然这里说的不能重写指的是父类的非抽象方法,父类的抽象方法是可以自己去实现的。

如果通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的概率会非常大。

具体的实现方式:

1、子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法。

2、子类中可以增加自己特有的方法。

3、当子类重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。

4、当子类实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。

三、依赖倒置原则(Dependence Inversion Principle,DIP)

内涵

  1. 是程序要依赖于抽象接口,不要依赖于具体实现,上层模块不应该依赖底层模块,它们都应该依赖于抽象。
  2. 抽象不应该依赖细节。
  3. 细节应该依赖抽象。

​​面向过程​​的开发,上层调用下层,上层依赖于下层,当下层剧烈变动时上层也要跟着变动,这就会导致模块的复用性降低而且大大提高了开发的成本。

​​面向对象​​​的开发很好的解决了这个问题,一般情况下抽象的变化概率很小,让​​用户程序​​​依赖于抽象,实现的细节也依赖于抽象。即使实现细节不断变动,只要抽象不变,客户程序就不需要变化。这大大降低了客户程序与实现细节的​​耦合度​​。

其核心思想是:是要面向接口编程,不要面向实现编程。

面向接口编程有啥好处?就好比是电脑,CPU、内存、硬盘、主板都是针对接口设计的,也就是定义好接口之后,任何一家厂商都可以生产对应的部件,最后组装起来就能工作。假如不针对接口设计,那么各模块之间就可能是耦合的,假如内存坏了,可能就不仅需要更换内存,可能连带着主板等都要更换。

关于DIP的内涵需要举例说明,不然这样一说还是不易理解。

我们看下面的例子:

public class Driver {

public void drive(Geely geely) {
System.out.println("老司机开始飙车....");
}
}


public class Geely {

public void run() {
System.out.println("吉利汽车发动-->跑起来...");
}
}


public class Client {
public static void main(String[] args) {
Driver carGod = new Driver();
Geely geely = new Geely();
carGod.drive(geely);
}
}

 这里面有两个类 Driver 和 Geely,Driver依赖于Geely可以看成是上层模块,Geely是下层基础模块。这是很自然的一个依赖,但自然的未必是合适的,虽然也能实现功能。比如,现在车神carGod不想开吉利了,要开宝马了,怎么办?很显然不太容易实现,因为Driver 直接依赖 Geely 类,强耦合,Driver里面没有能够实现开宝马或其他车的功能。这显然不合理啊,一个车神却只能开吉利! 要是非要开宝马,那除了新增BMW类以外,还要修改Driver类,使它具有开宝马的功能。你肯定在想这也挺简单啊,也没做太多修改啊,那是这个例子代码逻辑很简单,假如Driver类很复杂,业务功能很丰富,这时你再修改肯定很费劲,你要全面梳理后才敢动手修改,修改后还要仔细测试一遍,不然bug会把你淹没。实际上这样做也不符合“开闭原则”。

那么怎么做更合理呢?其实之所以会有上面的问题主要是 Driver 和 Geely 两个类耦合性太强,要降低耦合度。可以分别在 Driver 和 Geely 类上抽象出 Idriver 和 ICar 接口,如下:

/**
* @Author: Feng Ge
* @Date: 2020年4月15日09:18:46
**/
public interface ICar {

void run();

}

public class BMW implements ICar {

@Override
public void run() {
System.out.println("宝马汽车发动-->跑起来...");
}
}

public interface IDriver {

void drive(ICar Car);

}

public class Driver implements IDriver{

@Override
public void drive(ICar car) {
car.run();
System.out.println("老司机开始飙车....");
}
}


public class Client {
public static void main(String[] args) {
IDriver carGod = new Driver();
ICar car = new BMW();
carGod.drive(car);
}
}

益处

这样两者传递参数时是通过抽象接口来实现,比如Driver类里的drive()方法之前传的是Geely类的对象,现在直接传它的上层接口引用(即接口传递,实际中还有构造方法传递setter方法传递)。这样修改后,无论以后怎样扩展Client类,都不需要再修改Driver类了(实际情况中,代表高层模块的Driver类将负责完成主要的业务逻辑,一旦需要对它进行修改,引入错误的风险极大)。

依赖倒置原则还有一个很大的好处就是:支持多人并行开发,比如这里只需要定义好 ICar 和 IDriver 两个接口后就可以分别并行开发Driver 和 各种车的业务逻辑,且各自的单元测试也可以独立运行,各自互不影响,这在多人协作开发时很重要。

实现方式

  1. 每个类尽量都有接口或者抽象类,或者抽象类和接口两者都具备
  2. 变量的表面类型尽量是接口或者抽象类
  3. 任何类都不应该从具体类派生
  4. 使用继承时尽量遵循里氏替换原则


四、单一职责原则(Single Responsibility Principle,SRP)

内涵

一个类应该有且仅有一个引起它变化的原因,否则类应该被拆分。

主要针对有一个类T负责两个不同的职责:职责P1和职责P2。当因为职责P1的需求发生改变而需要修改类T的时候,有可能会导致原本运行正常的职责P2功能发生故障。

解决办法就是遵循单一职责原则,分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1的时候,不会使职责P2发生故障风险。

另一种通俗的解释就是像是工厂里的流水线一样,每个车间基本上只做一件事,所有车间组合起来就是一个生产流程。我们写程序的时候也可以这样,将一个类的功能细化一下争取做到一个类只做一件事。

举个接口违背单一原则的例子:

public interface IAnimal {
public String getName();

public void setName(String name);

public Integer getAge();

public void setAge(Integer age);

public void save();

public void delete();

public void query();
}

 这个接口中,不仅管理着动物的基本信息,而且负责数据的持久化操作,一个接口的职责过多。这里是用接口举例,类也是一样。下面改成符合单一原则的代码如下:

public interface IAnimalInfo {
public String getName();

public void setName(String name);

public Integer getAge();

public void setAge(Integer age);
}


public interface IAnimalBehavior {

public void save();

public void delete();

public void query();
}

益处

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

  • 降低类的复杂度。一个类只负责一项职责,其逻辑肯定要比负责多项职责简单得多。
  • 提高类的可读性。复杂性降低,自然其可读性会提高。
  • 提高系统的可维护性。可读性提高,那自然更容易维护了。
  • 变更引起的风险降低。变更是必然的,如单一职责原则遵守得好,当修改一个功能时,能显著降低对其他功能的影响。


实现方式 

重点是 职责的抽象 和 拆分。

五、接口隔离原则(Interface Segregation Principle,ISP)

内涵

要为各个类建立它们需要的专用接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

类间的依赖关系应该建立在最小的接口上。

接口中的方法应该尽量少,不要使接口过于臃肿,不要有很多不相关的逻辑方法。

有点类似于单一职责原则,都是功能尽可能的简单单一,不要冗余太多其他不相关的。

单一职责原则主要是类与方法,而接口隔离原则却是对接口而言的。

益处

 将臃肿庞大的接口分解为多个粒度小的接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。

  • 接口隔离提高了系统的内聚性,减少了对外交互,降低了系统的耦合性。
  • 如果接口的粒度大小定义合理,能够保证系统的稳定性;但是,如果定义过小,则会造成接口数量过多,使设计复杂化;如果定义太大,灵活性降低,无法提供定制服务,给整体项目带来无法预料的风险。
  • 使用多个专门的接口还能够体现对象的层次,因为可以通过接口的继承,实现对总接口的定义。
  • 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法,当实现这个接口的时候,被迫设计冗余的代码。


实现方式 

在具体应用接口隔离原则时,应该根据以下几个规则来衡量:

  • 接口尽量小,但是要有限度。一个接口只服务于一个子模块或业务逻辑。
  • 为依赖接口的类定制服务。只提供调用者需要的方法,屏蔽不需要的方法。
  • 了解环境,拒绝盲从。每个项目或产品都有选定的环境因素,环境不同,接口拆分的标准就不同深入了解业务逻辑。
  • 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

一个类被改变的原因不能超过一个,也就是说,一个类只有一个职责,如果职责过多,代码就会臃肿,可读性更差,也更难以维护。试想一个拥有很多方法的接口,所有实现它的类丢要实现这些方法,这个实现类就会变得很臃肿,而且实现的方法中有很多可能都用不到。

其实上单一职责原则和接口隔离原则有一定的关系,接口隔离以后,职责就单一了,实现这个接口的类的职责自然也就单一了。但是接口隔离关注的是抽象层,单一职责关注的是两者兼而有之,偏重于实现。

六、迪米特法则(Law of Demeter,LoD)

内涵

只与你的直接朋友交谈,不跟“陌生人”说话。一个对象应该对其他对象有最少的了解。

如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。

那么什么又是直接的朋友呢?出现在成员变量、方法的输入输出参数中的类就是直接的朋友。这些对象同当前对象存在关联、聚合或组合关系,可以直接访问这些对象的方法。

public class Teacher {

public void comment(GroupLeader groupLeader) {
Student[] students = new Student[100];
groupLeader.count(students);
}
}

public class GroupLeader {

public void count(Student [] students){
System.out.println("统计人数: " + students.length);
}
}

在这个例子中 Teatcher 类有两个朋友,一个是GroupLeader(Teatcher的方法参数),一个是Student(方法体中使用)。按照“直接朋友”的定义,只有GroupLeader是直接朋友。

但是 Teatcher 和非直接朋友 Student 也建立了联系,这就违反了迪米特法则,方法是类的行为,方法体中出现非直接朋友时就要警惕是否违反迪米特法则。

上面的代码可以这样来修改:

public class Teacher {

public void comment(GroupLeader groupLeader) {
groupLeader.count();
}
}

public class GroupLeader {

private Student[] students = new Student[100];

public void count(){
System.out.println("统计人数: " + this.students.length);
}
}

这样修改后,每个类都只和直接的朋友交流,有效减少了类之间的耦合。

益处

  • 降低了类之间的耦合度,提高了模块的相对独立性。
  • 由于亲合度降低,从而提高了类的可复用率和系统的扩展性。


实现方式 

  • 从依赖者的角度来说,只依赖应该依赖的对象。
  • 从被依赖者的角度说,只暴露应该暴露的方法。

所以,在运用迪米特法则时要注意以下6点:

  1. 在类的划分上,应该创建弱耦合的类。类与类之间的耦合越弱,就越有利于实现可复用的目标。
  2. 在类的结构设计上,尽量降低类成员的访问权限。
  3. 在类的设计上,优先考虑将一个类设置成不变类。
  4. 在对其他类的引用上,将引用其他对象的次数降到最低。
  5. 不暴露类的属性成员,而应该提供相应的访问器(set方法和get 方法)。
  6. 谨慎使用序列化(Serializable)功能。


 七、合成复用原则(Composite Reuse Principle,CRP)

内涵

它要求在软件复用时,要尽量先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现。

假设有一个A类,里面有两个方法,有一个类B想要复用这两个方法,请问有几种方案?

① 首先,最容易想到的就是继承,B类只要继承A类,就可以复用A类的方法 。

那这种方案肯定是不好,因为这会让B类和A类的耦合性增强,A类的其他方法可能B类并不想复用,但是也继承下来了。

② 可以在B类增加一个属性,类型为A,通过set的方式传入值,就可以复用A类的方法。

③ 同样,也可以把类A当作B类方法入参的类型,也可以达到复用的效果。

后面的两种方式就是合成复用原则推荐我们使用的。当然,如果要使用继承关系,则必须严格遵循里氏替换原则。

益处

通常类的复用分为继承复用和合成复用两种,继承复用虽然有简单和易实现的优点,但它也存在以下缺点:

  • 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类,父类对子类是透明的,所以这种复用又称为“白箱”复用。
  • 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化,这不利于类的扩展与维护。
  • 它限制了复用的灵活性。从父类继承而来的实现是静态的,在编译时已经定义,所以在运行时不可能发生变化。

采用组合或聚合复用时,可以将已有对象纳入新对象中,使之成为新对象的一部分,新对象可以调用已有对象的功能,它有以下优点:

  • 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的,所以这种复用又称为“黑箱”复用。
  • 新旧类之间的耦合度低。这种复用所需的依赖较少,新对象存取成分对象的唯一方法是通过成分对象的接口。
  • 复用的灵活性高。这种复用可以在运行时动态进行,新对象可以动态地引用与成分对象类型相同的对象。


实现方式 

合成复用原则是通过将已有的对象纳入新对象中,作为新对象的成员对象来实现的,新对象可以调用已有对象的功能,从而达到复用。

总结

这7种设计原则是软件设计模式必须尽量遵循的原则,各种原则要求的侧重点不同:

◆ 开闭原则是总纲,它告诉我们要对扩展开放,对修改关闭。

◆ 里氏替换原则告诉我们不要破坏继承体系。

◆ 依赖倒置原则告诉我们要面向接口编程。

◆ 单一职责原则告诉我们实现类要职责单一。

◆ 接口隔离原则告诉我们在设计接口的时候要精简单一。

◆ 迪米特法则告诉我们要降低耦合度。

◆ 合成复用原则告诉我们要优先使用组合或者聚合关系复用,少用继承关系复用。


举报

相关推荐

0 条评论