Service 层有两种写法（其中第一种写法大家是耳熟能详）：
- 写法一：业务与【方法】对应。一个 Service 类中可以有多个方法，每个方法都代表着一个业务操作。这种情况下，Service 类的类名是以名词为核心，例如：StudentService 。
- 写法二：业务与【Service 类】对应。一个 Service 类只处理一个业务，Service 类中自然也就只有一个方法。这种情况下，Service 类的类名是以动词为核心，例如：AddStudentService 。
从代码量的角度来看，两种写法本质上是一样的。无非就是将多个业务方法放在一个 Service 类中，还是分开放在多个 Service 类中。
很容易猜到，这两种写法的优缺点是互补的。写法一的缺点在于：
- 随着业务功能和复杂程度的增加，Service 类中的方法会越来越多，不利于维护。
- 与业务相关的自定义的异常类、自定义的参数类等相关内容放在何处，如何命令等又是一堆令人纠结的问题。
Service 的第二种写法避免了第一种写法的上述问题：
- 一个 Service 只处理一个逻辑，每个 Service 类都具有针对性。结合固定的命名规则，未来在一大堆类中找某个负责特定业务的类，比从一个 Service 类的一大堆方法中找某一个方法要方便。
- 业务类和相关内容可以很方便地组织在一起。例如，Service 相关的自定义的异常类就可以直接以内部类的形式定义在 Service 内部。
不过，第二种写法也不是没有缺点。由于第一种写法中的一个 Service 演变成第二种写法中的多个 Service，那么在 Web 层（Controller）要引入一大堆的 Service ！
当然，我们有其他的办法和编程技巧来弱化，甚至消除第二种写法的缺点，让我们充分享受它的优点。
让 Controller 和 Service 解耦的思路
在硬件的领域有类似的问题：一台机器有多个【输入设备】和【数据处理设备】，输入设备和数据处理设备是多对多的关系，那么将输入设备和数据处理设备一一连接起来那么整个硬件会很臃肿，而且线路越多信号干扰就越大越明显，影响设备的正常运行使用。
对于这个问题，硬件领域的解决方案是：使用总线。
[图片上传失败...(image-5cbbb8-1646998629581)]
输入设备和数据处理设备不直接相连，都是各自与总线相连。输入设备将收集到的数据送到总线，总线（通过总线控制器）去判断这个数据是送给哪个数据处理设备处理。
这里就是 通过总线将输入设备和处理单元解耦：
- 数据处理单元不关心自己所处理的数据是由哪个设备采集的；
- 输入设备不关系自己所采集的数据将由哪个处理单元处理；
- 【什么输入设备采集的数据，交由哪个数据处理单元处理】由总线负责。
他山之石，可以攻玉。硬件领域中的成熟的解题思路可以在软件领域中借鉴、应用。
我们可以引入一个第三方，无论是什么业务处理，Controller 都是去调用这个第三方的方法，输入必要的参数。由这个第三方去考虑当前情况下应该去调用哪个 Service ，让第三方去调用这个 Service 。
简单来说，就是将以前的 Controller -> Service 的调用链路变为 `Controller -
Bus -> Service` 。
实现总线类 Bus 的关键
虽然，在这个解题思路中各个 Controller 不再关心它要调用哪个 Service，但是这个中间的第三方（我们姑且沿用硬件领域的概念也命名为 Bus 类）它仍然需要知道所有的调用关系！
其实，Bus 不需要去记录 Controller 与 Service 的对应关系，它只需要去记录参数数据类型与 Service 的对应关系 。
类比于生活中的场景，这个道理其实很简单。
- 这个人送来的食材是【豆腐】，你就找个【豆腐圆子机器】，把素材做成豆腐圆子；
- 这个人送来的食材是【鱼】，你就找个【鱼圆子机器】，把素材做成鱼圆子；
- 这个人送来的shi'cai是【猪肉】，你就找个【肉圆子机器】，把素材做成肉圆子。
至于这个人是张三、李四还是王五，其实对你而言是个次要问题。而且没人规定张三就只能送豆腐，不能送鱼和猪肉，什么人会送什么食材来是不可控的。
你要记录的并不是人和机器的关系，而是人送来的食材和机器的对应关系。
结合具体代码：
public XxxService {
public void process(String arg) { ... }
}
public YyyService {
public void process(Integer arg) { ... }
}
public ZzzService {
public void process(Double arg) { ... }
}
我们需要的效果是，当 Service 的使用者（Controller，或者是 main 方法）向 Bus 传入不同类型的参数时，Bus 要知道去调用哪个 Service 的 process 方法：
- 向 Bus 传入 String 类型参数时，Bus 要【知道】是去调用 XxxService 的 process 方法。下例 ① 处
- 向 Bus 传入 Integer 类型参数时，Bus 要【知道】是去调用 YyyService 的 process 方法。下例 ② 处
- 向 Bus 传入 Double 类型参数时，Bus 要【知道】是去调用 ZzzService 的 process 方法。下例 ③ 处
public Application {
public static void main(String[] args) {
Bus bus = ...;
bus.execute("hello"); // ①
bus.execute(9527); // ②
bus.execute(1.234); // ③
}
}
问题的关键在于：Bus 如何知道、记录 各种参数类型与 Service 的对应关系 ？
关键性的 HashMap
Bus 中需要由一个 HashMap 去记录参数类型及其 Service 的关系，以达到类似如下关系：
map.put(String.class, xxxService);map.put(Integer.class, yyyService);map.put(Double.class, zzzService);
一旦 hashMap 中存储了这样的信息，那么 Bus 的 process 方法的逻辑就类似如下：
map.get(String.class).process(); // xxxService.process()
map.get(Integer.class).process();// yyyService.process()
map.get(Double.class).process(); // zzzService.process()
使用泛型约束 Service 类
由于 Service 的 process 方法的参数可能会多种多样，但是 HashMap 又要求 Key 和 Value 的类型的一致。因此，将 Map 定义成 HashMap<Class<Object>, Object> map 显然过于宽泛，并不严谨。
为了让 HashMap 的类型更严谨而贴切，我们需要引入泛型，并对 Service 类及其它的 process 方法的参数作出“约定”。
当然，如下要求并非我们的最终要求和编码形式。
我们要求 Service 的 process 的参数必须实现如下接口：
public interface IArgument {
}
那么，Service 类则必须实现如下接口：
public interface IService<A extends IArgument> {
void process(A arg);
}
在这样的接口要求下，我们的 Service 类的 process 方法的参数将定义成如下形式：
public class AddStudentServiceArgument implements IArgument {
...
}
Service 类将定义成如下形式：
public class AddStudentService implements IService<AddStudentServiceArgument> {
@Override
public void process(AddStudentServiceArgument argument) {
...
}
}
完善 HashMap 的声明
一旦我们要求 Service 的 process 方法的参数和 Service 类必须实现特定的接口，那么我们之前所说的 HashMap 的声明将变得更加精确、严谨：
HashMap<Class<? extends IArgument>, IService<? extends IArgument>> map = new HashMap<>();
- HashMap 的 Key 是 IArgument 接口的实现类的类对象；
- HashMap 的 Value 是 IService 接口的实现类的对象；
