目录
常见的判断的代码
先列举一个常见的的if代码吧
public void ifCode(int valueCode) {
if (valueCode == 1) {
runMethod(1);
System.out.println("执行业务方法1");
}
if (valueCode == 2) {
runMethod(2);
System.out.println("执行业务方法2");
}
if (valueCode == 3) {
System.out.println("执行业务方法3");
}
}
public void runMethod(int code) {
System.out.println("执行业务逻辑:" + code);
}
以上我们在代码非常常见的逻辑判断，在判断逻辑较为简单非常方便的直接，但现实往往很残酷
需求变了
我们的某某提新需求了：
现在需要增加业务逻辑4，和业务逻辑5，业务逻辑4和业务1的逻辑基本相同，除了有一些不同
没有办法，谁叫咱是程序猿呢，干吧
改完之后的代码就变成了这样子：
public void ifCode(int valueCode) {
if (valueCode == 1) {
runMethod(1);
System.out.println("执行业务方法1");
}
if (valueCode == 2) {
runMethod(2);
System.out.println("执行业务方法2");
}
if (valueCode == 3) {
System.out.println("执行业务方法3");
}
if (valueCode == 4) {
runMethod(1);
System.out.println("新增加的业务逻辑4");
}
if (valueCode == 5) {
System.out.println("新增加的业务逻辑5");
}
}
public void runMethod(int code) {
System.out.println("执行业务逻辑:" + code);
}
磕磕绊绊的系统上线了，
你以为就结束了吗？
Too young，Too simple，Too naive
新的需求又来了
这次某某又要求再修改下，再增加。。。。。
以上的场景在我们的开发中是不是很常见。。。，是不是这么的熟悉
是的，就是这样，我们的需求总在变的。
有没有办法让我们代码能更好的接受变更和修改呢？
答案当然是有的
我这里总结的是我平时工作中总结的一些方法，分享出来
抽象业务逻辑接口，然后容器化接口
1，Map化接口
还是来举个粟子，还是刚刚那if代码，我们换一种实现，使用抽象业务逻辑接口加容器化接口后代码会变成什么样？
public interface BusiServiceInf {
void busiService();
}
public class BusiServiceOperate1 implements BusiServiceInf {
public void busiService() {
CommonBusi.CommMethod(1);
System.out.println("执行业务逻辑1");
}
}
public class BusiServiceOperate2 implements BusiServiceInf {
public void busiService() {
CommonBusi.CommMethod(1);
System.out.println("执行业务逻辑2");
}
}
public class BusiServiceOperate3 implements BusiServiceInf {
public void busiService() {
System.out.println("执行业务逻辑3");
}
}
public class CommonBusi {
public static void CommMethod(int code) {
System.out.println("执行公共业务逻辑:" + code);
}
}
public class MultIfCode {
private static final Map<Integer, BusiServiceInf> BUSI_MAP = new HashMap<>();
static {
BUSI_MAP.put(1, new BusiServiceOperate1());
BUSI_MAP.put(2, new BusiServiceOperate2());
BUSI_MAP.put(3, new BusiServiceOperate3());
}
public void operate(int valueCode) {
BusiServiceInf busi = BUSI_MAP.get(valueCode);
if (null != busi) {
busi.busiService();
}
}
}
针对现有的代码，需求变更来了，用户要求增加业务4和业务5
public class BusiServiceOperate4 implements BusiServiceInf {
public void busiService() {
CommonBusi.CommMethod(1);
System.out.println("执行业务逻辑4");
}
}
public class BusiServiceOperate5 implements BusiServiceInf {
public void busiService() {
System.out.println("执行业务逻辑5");
}
}
public class MultIfCode {
private static final Map<Integer, BusiServiceInf> BUSI_MAP = new HashMap<>();
static {
BUSI_MAP.put(1, new BusiServiceOperate1());
BUSI_MAP.put(2, new BusiServiceOperate2());
BUSI_MAP.put(3, new BusiServiceOperate3());
BUSI_MAP.put(4, new BusiServiceOperate4());
BUSI_MAP.put(5, new BusiServiceOperate5());
}
public void operate(int valueCode) {
BusiServiceInf busi = BUSI_MAP.get(valueCode);
if (null != busi) {
busi.busiService();
}
}
}
针对新的需求变更，只需要增加两种新的业务实现即可，不用再对以前的业务代码做出任务的修改，业务代码相互独立，可对其中的业务逻辑进行修改，每个业务的修改不会影响到其他任务的执行。
但这个代码同样的，也有瑕疵，那就是每次扩展一个接口都需要手动将对象的实例添加到实例容器中(BUSI_MAP.put(1, new BusiServiceOperate1());)
像一般的业务场景，即可满足；
但如果是允许外部注册业务实现，那又该怎么实现呢？
像这种业务需求，可将Map中类信息，写入到配制文件中，然后通过配制文件加载所有的类信息，这样每次可新增加一个实现和手动向配制文件中添加一个实现类的信息
2，使用List存储接口
还是再举个粟子，需求又发生了改变，要让所有用户都执行标准的流程， 例如流程是先执行业务流程1，再执行业务流程4，再流程业务流程5，这样，只需要将原来的流程进行简单的改造就可以实现
public class MultIfCodeList {
private static final List<BusiServiceInf> BUSI_LIST = new ArrayList<>();
static {
BUSI_LIST.add(new BusiServiceOperate1());
BUSI_LIST.add(new BusiServiceOperate4());
BUSI_LIST.add(new BusiServiceOperate5());
}
public void operate(int valueCode) {
for (BusiServiceInf busi : BUSI_LIST) {
busi.busiService();
}
}
}
总结
通过刚刚列举的两个例子，我已经向你展示了抽象业务逻辑接口加容器化接口如何应用其中，通过容器与接口的组合可以达到流程控制的效果，在代码的可扩展上和可读性上面做的更好，但也不是100%完美的，类的数量会变的更多，将原来垂直的代码横向切分到多个类中，代码会更难于理解，这个平衡需要平时在写代码的时候，多思考该如何选择，讲到这，我给一个自己平时的标准吧，当对同一个条件的分支达到3个或者更多，我就会选择切换到使用容器化接口中，我的代码分享就到这里吧，欢迎给我评论,写下你的疑惑和问题。如果你有更好的意见，欢迎跟我交流
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
