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

前面举过一个面向接口编程的例子。在系统中写日志有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位的数字。因为超过这个长度的话，会增加记忆的难度。