设计模式(一)——面向对象六大原则

·  阅读 888

本文原创掘金:L_Sivan

记在前面:这个《设计模式》系列的文章,想了很久才决定写的,一是还是本人的原则,只有通过自己表达出来的东西,才是真正属于你的东西,所以即使写的不好,有什么理解不到位的,被人指出来也挺好的,证明属于我的东西还是有缺漏嘛。二是设计模式这个东西有点虚,特别这篇原则,总觉得还欠缺很多理解。三是看了好几篇设计模式,下面的讨论基本分两种,要么就是一堆Mark,要么就是一堆FXXk,也是有点担心会被骂吧,不过错了被指正也是很正常。不说废话了,上正文。

一. 单一职责原则

  • 定义:不要存在多于一个导致类变更的原因。简单说,就是一个类只负责一项职责。
  • 为什么要这个原则:试想,一个类T,用来实现两个职责t1和t2,在需求变更的情况下需要修改t1,可能导致原本正常工作的t2职责出错。

但是这个原则,其实看到的话,很多人应该都会觉得没啥好看的吧,因为太简单了,而且在写代码的时候,应该都不希望因为修改了一个功能导致其他的功能发生故障。 但是翻了好几篇博客,还有看到的书的作者也是说到,其实并没有很多类设计能完全遵守到单一职责原则,因为这个原则受太多因素制约了,比如下面这个例子:

我们要造车,然后要车跑起来

public class Car {
	public void run(String carType){
		System.out.println("启动"+carType+"引擎跑起来了");
	}	
}
public class Client {
	public static void main(String[] args) {
		Car c = new Car();
		c.run("BMW");
		c.run("Benz");
	}
}
结果:
  启动BMW引擎跑起来了
  启动Benz引擎跑起来了
复制代码

后面发现还有类似上世纪的小包车这种需要拉才能跑起来的车,我们怎么办呢? 首先按照单一职责原则,我们来另起一个类,来实现这个功能

public class Trolley {
	public void run(String carType){
		System.out.println("拉着"+carType+"跑起来了");
	}
}
public class Client {
	public static void main(String[] args) {
		Car c = new Car();
		c.run("BMW");
		c.run("Benz");
		Trolley trolley = new Trolley();
		trolley.run("上世纪的小包车");
	}
}
结果:
启动BMW引擎跑起来了
启动Benz引擎跑起来了
拉着上世纪的小包车跑起来了
复制代码

但是这里就有一个问题了,如果后期还有斗车这种要推的车,还有自行车这种要骑的车,还有几十种其他的车,那我们难道要一个类一个类的写吗?这样会造成类膨胀的。而且修改了类,还得大幅度修改客户端 所以在这里,再引入这个原则的同时,就得违背下这个原则了,如下:

public class Car {
	public void run(String carType){
		System.out.println("启动"+carType+"引擎跑起来了");
	}
	public void run2(String carType){
		System.out.println("拉着"+carType+"跑起来了");
	}
}
public class Client {
	public static void main(String[] args) {
		Car c = new Car();
		c.run("BMW");
		c.run("Benz");
		c.run2("上世纪的小包车");
	}
}
结果:
启动BMW引擎跑起来了
启动Benz引擎跑起来了
拉着上世纪的小包车跑起来了
复制代码

这样做的一个好处就是方便,直接在类里面新添加一个方法,在客户端只需要做小小的改动就可以用。这只是其中一个办法,当然,还有很多种办法,比如在run方法中根据carType判断来选择方式等等,但是这都违背了单一职责原则。所以这个原则怎么用呢?个人理解,很多时候我们在实际的编码过程中并不能完全遵守这个原则,我们只能尽量做到这个原则。不然的话就是死守教规了。

二. 里氏替换原则

  • 定义:所有引用父类的地方必须能透明地使用其子类的对象。

  • 为什么要用这个原则:试想一下,在一个类P1中,实现了方法m1,然后现在需要扩展m1方法,新的方法m2由P1的子类来完成,在完成m2的同时,有可能会将m1的方法破坏掉,使得m1不能正常工作。

上代码,还是用上文的例子:

public class Car {
	public void run(String carType){
		System.out.println("启动"+carType+"引擎跑起来了");
	}
}
public class Client {
	public static void main(String[] args) {
		Car c = new Car();
		c.run("BMW");
	}
}
结果:
启动BMW引擎跑起来了
复制代码

现在需要加一个功能,就是对行车的速度进行汇报,怎么做?首先想到的是不是直接修改Car的run方法,但是要注意,这个不是一个好的方法,修改了这个run方法,可能会导致本来在使用这个方法的其他对象产生错误的结果,所以不能这样,我们使用继承,然后重写run方法,如下:

public class AdvancedCar extends Car{
	@Override
	public void run(String carType) {
		super.run(carType);
		System.out.println("车的速度是80KM/h");
	}
}
public class Client {
	public static void main(String[] args) {
		AdvancedCar car = new AdvancedCar();
		car.run("BMW");
	}
}
结果:
启动BMW引擎跑起来了
车的速度是80KM/h
复制代码

然后这里的确实现了功能,而且代码还很整洁,只是一个继承然后加多一句就好了,但是问题就来了,假设再来需求,上班高峰期的时候塞车,不需要汇报速度,下班加班赶回家才需求汇报速度(保平安嘛),那咋办?在这个AdvancedCar中,run方法一经调用,就会汇报速度的喔。用里氏替换原则来看,Car出现的地方,AdvancedCar就不能用了,我们来用里氏替换原则修改下代码:

public class AdvancedCar extends Car{
	public void showSpeed(){
		System.out.println("车的速度是80KM/h");
	}
}
public class Client {
	public static void main(String[] args) {
		AdvancedCar car = new AdvancedCar();
		car.run("BMW");
		car.showSpeed();
	}
}
结果:
启动BMW引擎跑起来了
车的速度是80KM/h
复制代码

这样修改之后,Car出现的地方,AdvancedCar也能直接使用,因为run方法的原有功能并没有被破坏,而且要满足上一段需求的话,只需要直接在Client这里加判断就好。 所以我自己的粗略理解就是:子类可以扩展父类的方法,但不应该复写父类的方法。

三. 依赖倒置原则

  • 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

  • 为什么要用这个原则:假设一个类P组合了一个类A,然后用A实现了相关的功能,然后现在要将A实现的功能改成B类来实现,这里的修改方法是只能去修改P的代码,而这种直接修改代码是会带来不必要的风险的。

上例子,还是用车的例子:

public class Car {
    // 给汽车加油
	public void refuel(Gasoline90 gasoline){
		System.out.println("加了型号为"+gasoline.getClass().getSimpleName()+"的汽油");
	}
}
public class Gasoline90 { }
public class Client {
	public static void main(String[] args) {
		Car car = new Car();
		car.refuel(new Gasoline90());
	}
}
结果:
加了型号为Gasoline90的汽油
复制代码

现在问题来了,加油站没有90汽油了,只有93和97,而汽车没油了,难道但是加油refuel(Gasoline90 gasoline)只能加90汽油,咋办,难不成直接修改car的代码,给它多加两个方法,分别可以加93和97汽油?很明显不科学嘛,一点代码复用都没有,更别谈设计模式了,所以在这里,就要改了。

// 定义一个接口Gasoline
public interface Gasoline { }

//在Car类的refuel方法中传入Gasoline参数
public class Car {
	public void refuel(Gasoline gasoline){
	System.out.println("加了型号为"+gasoline.getClass().getSimpleName()+"的汽油");
	}
}

// 写90和97两个汽油的类
public class Gasoline90 implements Gasoline{ }
public class Gasoline97 implements Gasoline{ }

// 场景
public class Client {
	public static void main(String[] args) {
	Car car = new Car();
 //car.refuel(new Gasoline90());
	System.out.println("----汽车站没有90汽油了-----");
	car.refuel(new Gasoline97());
	}
}

结果:
----汽车站没有90汽油了-----
加了型号为Gasoline97的汽油
复制代码

在上面的例子,传参的时候传入了一个Gasoline类型,只要汽车要加的汽油,全都实现这个借口,就可以让汽车自由加油,管它什么93,97,1997都好,而且还不用修改Car的代码,只需要实现Gasoline接口就好。

四. 接口隔离原则

咋看一下,我以为像现实生活中那样,隔离病原体是把病原体隔离开来,那接口隔离原则难道是隔离接口?编程界的名词确实不能一般对待。

  • 定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上
  • 为什么需要这个原则:假想我们设计了一个接口I,里面有五个方法,分别是m1,m2,m3,m4,m5,而有两个类A和B,分别需要用m1m2m5,m3,m4,m5方法。那么无论是那一个类,在实现接口I的时候,都要将其本身不需要的类进行实现,很明显,这不是一个好设计。 上代码,还是用车的例子:
// 接口
public interface ICar {
	public void run(String carType);
	public void showSpeed();
	public void playMusic(String songName);
}

// 实现类
public class Car implements ICar{
    public void run(String carType){
     System.out.println("启动"+carType+"引擎跑起来了");
	}
	public void showSpeed() {
     System.out.println("汽车的速度为80KM/h");
	}
	public void playMusic(String songName) {
	System.out.println("放起了动听的"+songName);
	}
}

// 场景
public class Client {
	public static void main(String[] args) {
	Car car = new Car();
	car.run("BMW");
	car.showSpeed();
	car.playMusic("成都");
	}
}
复制代码

这里问题就来了,并不是所有的车都有放音乐的功能,也并不是所有的车都有展示速度的功能,但是只有上面代码这个车的话,我们在新建其他车对象的时候,却带上了全部的功能,显然,这是不科学的。改进下,将上面的接口拆分成两个接口专业的车IProfessionalCar和娱乐功能的车IEntertainingCar

// 接口
public interface IProfessionalCar {
	public void run(String carType);
	public void showSpeed();
}
public interface IEntertainingCar {
	public void run(String carType);
	public void playMusic(String songName);
}

// 实现类
public class ProfessionalCar implements IProfessionalCar {
	public void run(String carType){
	System.out.println("启动"+carType+"引擎跑起来了");
	}
	public void showSpeed() {
	System.out.println("汽车的速度为80KM/h");
	}
}
public class EntainingCar implements IEntertainingCar {
	public void run(String carType){
	System.out.println("启动"+carType+"引擎跑起来了");
	}
	public void playMusic(String songName) {
	System.out.println("放起了动听的"+songName);
	}
}

// 场景
public class Client {
	public static void main(String[] args) {
	IProfessionalCar professionalCar = new ProfessionalCar();
	professionalCar.run("F1方程式");
	professionalCar.showSpeed();
	EntainingCar entainingCar = new EntainingCar();
	entainingCar.run("坏了速度仪表盘的SUV");
	entainingCar.playMusic("成都");
	}
}
结果:
启动F1方程式引擎跑起来了
汽车的速度为80KM/h
启动坏了速度仪表盘的SUV引擎跑起来了
放起了动听的成都
复制代码

接口隔离原则的要求我们,建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。这通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。

五. 迪米特法则

  • 定义:一个对象应该对其他对象保持最少的了解。
  • 为什么需要这个原则:原因就是一个对象对另一个对象了解得越多,那么,它们之间的耦合性也就越强,当修改其中一个对象时,对另一个对象造成的影响也就越大。

上例子,还是用车:

// 车
public class Car {
	private String carType;
	public Car(String carType){
		this.carType = carType;
	}
	public void run(){
		System.out.println("启动"+carType+"引擎跑起来了");
	}
	public void refuel(Gasoline gasoline){
		System.out.println("加了型号为"+gasoline.getName()+"汽油");
	}
}
// 汽油
public class Gasoline {
	private String name;
	public Gasoline(String name) {
		this.name = name;
	}
	public String getName() {
		return name;
	}
    private boolean quality = true;
	public boolean getQuality(){
		return this.quality;
	}
}
// 人
public class Person {
	private Car car;
	public void setCar(Car car) {
		this.car = car;
	}
	public void drive(){
		car.run();
	}
	public void refuel(Gasoline gasoline){
        if(gasoline.getQuality()){
			System.out.println("油的质量过关,可以放心加");
			car.refuel(gasoline);
		}
}
// 场景类
public class Client {
	public static void main(String[] args) {
		Person jack = new Person();
		jack.setCar(new Car("Suv"));
		jack.drive();
		System.out.println("*********开了三百公里,没油了********");
		jack.refuel(new Gasoline("90"));
	}
}
结果:
启动Suv引擎跑起来了
*********开了三百公里,没油了********
油的质量过关,可以放心加
加了型号为90汽油
复制代码

我们可以看到,一个很符合生活的场景,jack开车,然后开太久了,没油了,于是加油,但是问题就来了,在生活中,加油这个动作应该是jack和加油站的工作人员进行交涉,然后由加油站的工作人员来完成,而在上面这里,则是由jack自己完成。而且对油的质量的检验,我们普通人怎么会,肯定不行啊,万一90,93,97的检验方法各不相同,万一以后的油质量越来越不好,检验步骤要变,难道要修改Person类的方法,不对啊。 我们来改下

// 增加类加油站工人
public class WorkerInPetrolStation {
	public void refuel(Car car, String gasolineName) {
	Gasoline gasoline = new Gasoline(gasolineName);
	if (gasoline.getQuality()) {
	System.out.println("油的质量过关,可以放心加");
	car.refuel(gasoline);
	}
	}
}
// 将Person的refuel方法修改成依赖工人
public class Person {
	private Car car;
	public void setCar(Car car) {
	this.car = car;
	}
	public void drive(){
	car.run();
	}
	public void refuel(WorkerInPetrolStation worker, String gasolineName){
	worker.refuel(this.car, gasolineName);
	}
}
// Car,Gasoline不变
// 场景类
public class Client {
	public static void main(String[] args) {
	Person jack = new Person();
	jack.setCar(new Car("Suv"));
	jack.drive();
	System.out.println("*********开了三百公里,没油了********");
	jack.refuel(new WorkerInPetrolStation(),"90");
	}
}
结果:
启动Suv引擎跑起来了
*********开了三百公里,没油了********
油的质量过关,可以放心加
加了型号为90汽油
复制代码

现在无论以后油那边怎么变,都和我们Persion无关,交给加油站工人嘛,这是他们的饭碗。 迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。但是凡事都有度,虽然可以避免与非直接的类通信,但是要通信,必然会通过一个“中介”来发生联系。过分的使用迪米特原则,会产生大量这样的中介和传递类,导致系统复杂度变大。

六. 开闭原则

  • 定义:对修改关闭,对扩展开放
  • 为什么使用这个原则:这不就是代码重用的一个终极目标吗,不实现这个原则,改代码改到怀疑人生啊!而上面的五个原则,其实就是这个原则的体现。 但是这个原则,正是因为太高级了,所以太虚了,虚的没什么套路可寻,只能靠经验,领悟来慢慢体会。

总结:

以上就是我对这六个原则的简单理解,例子也不知道举得恰不恰当,文字的描述也不知道是不是到位,但是这也就是我的理解了,等深入这行有一定时间,或许会对这篇东西觉得很傻,噗嗤一声,完全不屑。但也是以后的事了。 欢迎前来责骂。。。

分类:
阅读
标签:
收藏成功!
已添加到「」, 点击更改