could not load avaliable ZIP files.pull down to try again 已解决

Xml简介与行业应用

  返回  

这条编程规范如何?——条件分支超过6个时必须改为接口

2021/7/21 0:46:14 浏览:

前面举过一个面向接口编程的例子。在系统中写日志有3种不同的实现:

  1. 写到日志文件。
  2. 写到数据库。
  3. 写到本地的一个日志服务的UDP端口。

按照常规的思维逻辑,可以用一种最直接的写法。如下方案一。

方案一

public class LogController {
	private LogService logservice;
	void writeLog(SysLogInfo logInfo){
		switch(logType){
		case LT_FILE:
			logservice.writeToFile(logInfo);
			break;
		case LT_DB:
			logservice.writeToDb(logInfo);
			break;
		case LT_UDP:
			logservice.writeToUdp(logInfo);
			break;
		default:
			break;
		}		
	}
}

当然,这一方法遭到很多面向接口编程的拥护者的反对,他们认为这样违反了OCP原则。即:每当新增一种日志类型时,就要修改writeLog方法。

于是提倡把写日志的功能抽象到接口中。如下方案二。

方案二

基于不同的实现写3个不同的实现类:

public class LogServiceFile implements LogService{
}
public class LogServiceDB implements LogService{
}
public class LogServiceUdp implements LogService{
}

在调用该接口的地方采用GetLogServiceInst动态的获取对应的派生类对象。这样在新增日志类型时,就避免了对writeLog方法的修改。

public class LogController {
	private LogService logservice;
	void writeLog(SysLogInfo logInfo){
		logservice = GetLogServiceInst();
		logservice.addLog(logInfo);
	}
}

孰优孰劣

两种方法孰优孰劣呢?如果一味的要求使用方案二,我认为太过学究,不切实际。如果只会方案一,则太过笨拙,不动脑筋。

选择使用哪个方案,关键在于需要判断场景是否有可能发生变化。例如物质间的相互作用力,包含:电磁力、强力、弱力、万用引力,四种。那么固定的写成这样也未尝不可。

public class ForceClac{
	public Newton getForce(){
		switch(forType){
		case FT_Elec:
			return getElectromagneticForce();
		case FT_Strong:
			return getStrongForce();
		case FT_Weak:
			return getWeakForce();
		case FT_Gravity:
			return getGravitationalForce();
		}
	}
}

因为谁也不知道第五种力什么时候才会被发现!在发现之前,getForce是不会被修改的,也就无从谈论是否会违反OCP原则的问题。

但实际工作如何决定使用哪个方案呢?《重构》一书中指出,在第二次修改的时候进行重构。因为再一再二不再三!但是这个策略在实际工作中很难进行量化,懒惰的开发人员会找出一万种理由告诉你:这只是他的第一次!

因此我建议,条件分支超过6个时必须改为接口。即:使用方案一时适合条件分支小于或等于6的场景;当条件分支大于6时,采用方案二。为什么是6,而不是5或7或8?其实可以根据项目组的实际情况进行调整。我之所以建议用6,理由只有一个:人类短时记忆的数字上限是6个。例如我们在很多场景需要输入短信验证码时,一般最多会使用6位的数字。因为超过这个长度的话,会增加记忆的难度。

联系我们

如果您对我们的服务有兴趣,请及时和我们联系!

服务热线:18288888888
座机:18288888888
传真:
邮箱:888888@qq.com
地址:郑州市文化路红专路93号