从if else到解耦

我们在写一段复杂的条件判断的时候if,switch算是常用手段了。随着逻辑的复杂,如果if嵌套5层,相信代码的可读性已经是比较差了,需要在整个方法上加注解来说明为什么这么写,这已经不是一个人容易摸索出来的情况了。
我们想象一下如何继续在这样的代码上继续迭代,首先得写好自己的新增逻辑,然后再控制器的类上加上if判定。如果一直新增,或者条件修改,那么控制类一定要跟着变。这样的情况明显是违背开闭原则的。增加或者修改都得修改控制类。

改良1 配置文件

造成上面必须修改控制类的一个重要原因是if这样的逻辑是硬编码到代码的。这样的过程其实是可以抽取成为配置文件的。
文件的修改是方便的,起码是不用再次编译代码了。已经达到一定程度的对扩展开放了,例如过滤器。
但是这种情况一般是对外提供的服务使用的方式,如果是一个项目,这个真没有硬编码来的实在,ide有扫描类的功能,可以发现哪些类没有被使用,写配置文件的方式就很容易忽略掉配置这个步骤。

改良2 再次抽象

我们写的if else代码。其实每次都要写实现过程以及如果判断能这么实现的方式或者标志。
以简单工厂模式为例,如果我们想实现一个创建操作实体类的工厂,我们的代码基本是下面这么写的

    public static Operation createOperation(String demo) {
        switch (demo) {
            case "A":
                operationObj = A();
                break;
            case "B":
                operationObj = B();
                break;
        }
        return operationObj;
        }

我们使用的是java编码,我们可以利用java的特性来缩减上面的过程

Class.forName(demo).newInstance()

这里使用了java的一个特性,就是通过class对象创建实例,我们是如何省去选择语句的逻辑的呢?
靠约束。这里定义了类名必须是和传入参数一样的名字。如果说if else是线性查找,及他是一个一个从开头一直找到合适的。那么上面的方式,我们采取的就是散列的模式,直接定位。

对比

我们通过上面的两个案例,来对比一下(下面称线性模式,散列模式)。线性模式的特点是可读性强,都有明确的判定,这个到底是什么情况进入。散列模式因为加了抽象,作为了更通用的模式,他阅读起来相对不友好,需要很多注释和约束来控制,否则就会出现大家看着逻辑莫名其妙的情况。散列模式定位更快,线性模式随着判断阅读会越来慢,可能if判定了20次都没到具体的判断上。散列模式如何描述规范是个很大的问题,尤其是规范可能是不好描述的。举个例子,我们真实的场景不单单是创建个对象,可能if判断是创建什么对象,调用什么方法。这个才是我们真是需要的。我们举的例子明显不满足这种情况。

下面就说一种最佳实践

当注解遇到spring

java中的注解,我们在spring中用的特别多,但是自定义注解的情况,相对用的少。下面就通过自定义注解,达到解耦的目的。
首先构建自己的注解

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Executor {
	int exec();
}

把注解加入到具体的逻辑代码中

public interface Handler {
	@Executor(exec= 1)
	public void showInfo();
}	

具体的实现类就通过spring注解,让spring扫描到。
最后我们要做的就是维护判定关系。

@Component
public class Processor implements BeanPostProcessor {

	@Override
	public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
		return bean;
	}

	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {

		Class<? extends Object> clazz = bean.getClass();
		
		//获取方法上的注解维护一个结构
			...
		
	}

}

这里利用了spring构建类的功能,并且可以拿到对应的类,从中获取到方法的注解。自己组织一个map用来保存。

总结

从上面的逻辑上,我们可以看出,我们思维上判定的逻辑一个没少,通过解耦只是做到了扩展的时候写更少的代码,记住,是扩展的时候。有些情况扩展需要不大,if else大可以舒舒服服的用,这个需要开发者对业务有个比较好的把握。

点赞