一分钟学会如何提升你代码的开放性
1.引言
现实世界的事物都存在联系，我们不可能是一个独立的个体；软件世界也是如此，比如：在我们创建一个律所的时候，也需要去做很多事情，初始化该律所的权限、初始化该律所的文档资料库信息等等。
上述的那些关联是现在就已经知道的，但随着产品的发展，肯定会出现很多新的需求关联。
而优秀的工程师的职责就是解决当前已知关联，并为未来的新需求扩展提供开放性。
下文两种方式，阐述了如何在我们代码中提升这种开放性。
2.Spring的事件通知机制
Spring提供了事件广播的机制，其框架内部，也大量使用了该方式。
ApplicationEvent：表示某类事件，如：容器的初始化、我们新建了一个律所、新建了一个任务等等。
ApplicationListener：表示观察者的抽象，如：具体的观察者可以是任务新建后发出一个通知，创建一个关联账户等等。
ApplicationEventPublisher：事件的发布者，ApplicationContext实现了事件发布者的接口。
以下为代码示例：
/**
* 针对某类事情的发生，我们可以定义一个ApplicationEvent。
* 以后有针对这类事情的处理时，我们就可以实现一个自己的ApplicationListener。
* 将自己的业务写在该Listener中。
*/
class MyApplicationEvent extends ApplicationEvent {
public MyApplicationEvent(Object source) {
super(source);
}
}
/**
* 这里只是提供了一个示例的Listener，你完成可以针对MyApplicationEvent再扩展若干个自己业务的Listener
* 如：MyApplicationListenerTwo4MyBusiness
*/
@Component
class MyApplicationListenerOne4MyBusiness implements ApplicationListener {
@Override
public void onApplicationEvent(MyApplicationEvent event) {
//针对MyApplicationEvent，做我们自己的业务处理
System.out.println(event);
}
}
@Component
public class MyBusiness {
@Autowired
ApplicationContext applicationContext;
public void doBusiness() {
//此处撰写业务逻辑核心代码
//...
//对需要扩展开放的地方，发出事件通知
applicationContext.publishEvent(new MyApplicationEvent("hello world"));
}
}
3.自动注入同一接口的实现
本方法将需要扩展的地方抽象成一个接口，业务有扩展需求时，实现该接口即可。
本方法利用了Spring对List的依赖注入，类似的还有Map的注入，当然你如果直接通过接口获取指定类型的Bean也是可以的。
以下为代码示例：
/**
* 对需要扩展的地方，抽象成一个接口，有需要扩展的逻辑，实现该接口即可
*/
interface MyBusinessExtInterface {
void doExt(Object relatedObject);
}
/**
* 根据自己的相关业务，定义了一个扩展实现；我们可以根据自己的业务需要，定义若干个实现
*/
@Component
class MyBusiness4ExtOne implements MyBusinessExtInterface {
@Override
public void doExt(Object relatedObject) {
//这是根据当前业务扩展的一个关联业务的实现
System.out.println(relatedObject);
}
}
@Component
public class MyBusiness {
//此处自动注入了MyBusinessExtInterface的所有接口实现
@Autowired
List myBusinessExtInterfaceList;
public void doBusiness() {
//此处撰写业务逻辑核心代码
//...
//对需要扩展开放的地方，发出事件通知
for(inti =0, length =myBusinessExtInterfaceList.size(); i < length; i++) {
myBusinessExtInterfaceList.get(i).doExt("hello world");
}
}
}
4.总结
以上代码思路遵循了高内聚、低耦合及开闭原则的软件设计原则。
每一个业务自身内聚在自己的业务实现当中，并没有直接依赖到其他具体业务。在有新需求出现的时候，我们仅需要创建一个新的类来实现该接口，而不是让开发者找到原来的代码进行修改。
对开发工程师而言，找代码是痛苦的，添加新代码是愉悦的，因为这样不需要理解已有的代码逻辑。
而对测试工程师而言，不修改已有代码是快乐的，修改已有代码是悲催的，因为修改意味着原来已经测试的功能不稳定。
由于不需要对原来的代码进行修改，所以已有功能不受影响，仅需要测试新增代码，提升了代码的质量。
以上的描述更多是在系统内部进行开放，跨系统的协作我们会采用类似消息队列的方式进行，待后面再进行总结。
