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