导读
查尔斯·狄更斯在《双城记》中写道：“这是一个最好的时代，也是一个最坏的时代。”移动互联网的快速发展，出现了许多新机遇，很多创业者伺机而动；随着行业竞争加剧，互联网红利逐渐消失，很多创业公司九死一生。
笔者在初创公司摸爬滚打数年，接触了各式各样的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
