《Java工程师必读手册》——Java经验之谈系列——那些年，我们见过的Java服务端“乱象”（1）

导读

 

查尔斯·狄更斯在《双城记》中写道：“这是一个最好的时代，也是一个最坏的时代。”移动互联网的快速发展，出现了许多新机遇，很多创业者伺机而动；随着行业竞争加剧，互联网红利逐渐消失，很多创业公司九死一生。

 

笔者在初创公司摸爬滚打数年，接触了各式各样的Java微服务架构，从中获得了一些优秀的理念，但也发现了一些不合理的现象。现在，笔者总结了一些创业公司存在的Java服务端乱象，并尝试性地给出了一些不成熟的建议。

一、 使用Controller基类和Service基类

 

1. 现象描述

 

1) Controller基类

 

常见的Controller基类如下：

 

 

 

常见的Controller基类主要包含注入服务、静态常量和静态函数等，便于所有的Controller继承它，并在函数中可以直接使用这些资源。

 

2) Service基类

 

常见的Service基类如下：

 

 

 

常见的Service基类主要包括注入DAO、注入服务、注入参数、静态常量、服务函数、静态函数等，便于所有的Service继承它，并在函数中可以直接使用这些资源。

 

2. 论证基类必要性

 

首先，了解一下里氏替换原则：

 

• 里氏代换原则（Liskov Substitution Principle，简称LSP）：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

 

其次，了解一下基类的优点：

 

• 子类拥有父类的所有方法和属性，从而减少了创建子类的工作量；

• 提高了代码的重用性，子类拥有父类的所有功能；

• 提高了代码的扩展性，子类可以添加自己的功能。

 

所以，我们可以得出以下结论：

 

• Controller基类和Service基类在整个项目中并没有直接被使用，也就没有可使用其子类替换基类的场景，所以不满足里氏替换原则；

 

• Controller基类和Service基类并没有抽象接口函数或虚函数，即所有继承基类的子类间没有相关共性，直接导致在项目中仍然使用的是子类；

 

• Controller基类和Service基类只关注了重用性，即子类能够轻松使用基类的注入DAO、注入服务、注入参数、静态常量、服务函数、静态函数等资源。但是，忽略了这些资源的必要性，即这些资源并不是子类所必须的，反而给子类带来了加载时的性能损耗。

 

综上所述，Controller基类和Service基类只是一个杂凑类，并不是一个真正意义上的基类，需要进行拆分。

 

3. 拆分基类的方法

 

由于Service基类比Controller基类更典型，本文以Service基类举例说明如何来拆分“基类”。

 

1) 把注入实例放入实现类

 

根据“使用即引入、无用则删除”原则，在需要使用的实现类中注入需要使用的DAO、服务和参数。

 

 

2) 把静态常量放入常量类

 

对于静态常量，可以把它们封装到对应的常量类中，在需要时直接使用即可。

 

 

3) 把服务函数放入服务类

 

对于服务函数，可以把它们封装到对应的服务类中。在别的服务类使用时，可以注入该服务类实例，然后通过实例调用服务函数。

 

 

4) 把静态函数放入工具类

 

对于静态函数，可以把它们封装到对应的工具类中，在需要时直接使用即可。

 

接下篇：https://developer.aliyun.com/article/1228261?groupCode=java