第二部分:理论三

第二部分:理论三

理论三

如何理解“里式替换原则”?

  • 里式替换原则的英文翻译是:Liskov Substitution Principle,缩写为 LSP。
  • 子类对象(object of subtype/derived class)能够替换程序(program)中父类对象(object of base/parent class)出现的任何地方,并且保证原来程序的逻辑行为(behavior)不变及正确性不被破坏。
  • 举例传输数据的类,父类 Transporter ,其中传输数据的逻辑在一个方法 sendRequest 中。
  • 子类 SecurityTransporter 继承父类 Transporter ,重写方法 sendRequest ,并增加额外功能,支持传输 appId 和 appToken 安全认证信息。这样的设计符合里式替换原则。
  • 若重写方法 sendRequest ,并且在方法中抛出异常,那么子类的输出逻辑有所改变。这就不符合里式替换原则。
  • 多态是面向对象编程的一大特性,也是面向对象编程语言的一种语法。而里式替换是一种设计原则,是用来指导继承关系中子类该如何设计的,子类的设计要保证在替换父类的时候,不改变原有程序的逻辑以及不破坏原有程序的正确性。

代码示例:原本符合里式替换原则的代码

public class Transporter {
	private HttpClient httpClient;
	public Transporter(HttpClient httpClient) {
		this.httpClient = httpClient;
	}
	public Response sendRequest(Request request) {
		// ...use httpClient to send request
	}
}

/***
 *类 SecurityTransporter 的设计完全符合里式替换原则
 */
public class SecurityTransporter extends Transporter {
	private String appId;
	private String appToken;
	public SecurityTransporter(HttpClient httpClient, String appId, String app
		super(httpClient);
		this.appId = appId;
		this.appToken = appToken;
	}
	@Override
	public Response sendRequest(Request request) {
		if (StringUtils.isNotBlank(appId) && StringUtils.isNotBlank(appToken)) {
			request.addPayload("app-id", appId);
			request.addPayload("app-token", appToken);
		}
		return super.sendRequest(request);
	}
}

public class Demo {
	public void demoFunction(Transporter transporter) {
		Reuqest request = new Request();
		//... 省略设置 request 中数据值的代码...
		Response response = transporter.sendRequest(request);
		//... 省略其他逻辑...
	}
}
// 里式替换原则
Demo demo = new Demo();
demo.demofunction(new SecurityTransporter(/* 省略参数 */););

改造之后的代码:如果传递进 demoFunction() 函数的是父类 Transporter 对象,那 demoFunction() 函数并不会有异常抛出,但如果传递给 demoFunction() 函数的是子类 SecurityTransporter 对象,那 demoFunction() 有可能会有异常抛出。尽管代码中抛出的是运行时异常(Runtime Exception),我们可以不在代码中显式地捕获处理,但子类替换父类传递进 demoFunction 函数之后,整个程序的逻辑行为有了改变。

// 改造前:
public class SecurityTransporter extends Transporter {
	//... 省略其他代码..
	@Override
	public Response sendRequest(Request request) {
		if (StringUtils.isNotBlank(appId) && StringUtils.isNotBlank(appToken)) {
			request.addPayload("app-id", appId);
			request.addPayload("app-token", appToken);
		}
		return super.sendRequest(request);
	}
}
// 改造后:
public class SecurityTransporter extends Transporter {
	//... 省略其他代码..
	@Override
	public Response sendRequest(Request request) {
		if (StringUtils.isBlank(appId) || StringUtils.isBlank(appToken)) {
			throw new NoAuthorizationRuntimeException(...);
		}
		request.addPayload("app-id", appId);
		request.addPayload("app-token", appToken);
		return super.sendRequest(request);
	}
}

哪些代码明显违背了 LSP?

概述

  • 里式替换原则还有另外一个更加能落地、更有指导意义的描述,那就是“按照协议来设计”。
  • 子类在设计的时候,要遵守父类的行为约定(或者叫协议)。
  • 这里的行为约定包括:函数声明要实现的功能;对输入、输出、异常的约定;甚至包括注释中所罗列的任何特殊说明。

举例几个违反里氏替换原则

  • 子类违背父类声明要实现的功能,比如排序逻辑不同
  • 子类违背父类对输入、输出、异常的约定,上文例子就是异常不同
  • 子类违背父类注释中所罗列的任何特殊说明,可以用父类的单元测试来检测

课堂讨论

  • 用来约束使用继承语法的设计思路
  • 若子类与父类完全不同,天马行空,那么没有必要使用继承
  • 对调用者友好统一
上一篇:基于AD5420输出驱动4-20mA电流方案


下一篇:P3144 [USACO16OPEN]Closing the Farm S