改造一：dao 层实现类交给容器（@Component）#

1
package com.itheima.dao.impl;
2

3
import cn.hutool.core.io.IoUtil;
4
import com.itheima.dao.UserDao;
5
import org.springframework.stereotype.Component;
6

7
import java.io.InputStream;
8
import java.util.ArrayList;
9
import java.util.List;
10

11
@Component   // 将当前类交给 Spring 管理，声明为 Spring 容器中的 bean 对象
12
public class UserDaoImpl implements UserDao {
13

14
    @Override
15
    public List<String> list() {
16
        // 读取 user.txt 中的数据
17
        InputStream in = this.getClass().getClassLoader().getResourceAsStream("user.txt");
18
        return IoUtil.readUtf8Lines(in, new ArrayList<>());
19
    }
20
}

改造二：service 层实现类交给容器，并注入 dao（@Component + @Autowired）#

1
package com.itheima.service.impl;
2

3
import com.itheima.dao.UserDao;
4
import com.itheima.pojo.User;
5
import com.itheima.service.UserService;
6
import org.springframework.beans.factory.annotation.Autowired;
7
import org.springframework.stereotype.Component;
8

9
import java.time.LocalDateTime;
10
import java.time.format.DateTimeFormatter;
11
import java.util.List;
12

13
@Component   // 交给 IOC 容器管理
14
public class UserServiceImpl implements UserService {
15

16
    @Autowired   // 自动装配：应用程序在运行时，会自动的从容器中找到该类型的对象，并赋值给该变量
17
    private UserDao userDao;
18

19
    @Override
20
    public List<User> list() {
21
        // 1. 调用 dao 层，获取数据
22
        List<String> lines = userDao.list();
23

24
        // 2. 业务逻辑处理：解析数据，封装 User 对象 → List<User>
25
        List<User> userList = lines.stream().map(line -> {
26
            String[] split = line.split(",");
27
            return new User(
28
                    Integer.parseInt(split[0]), split[1], split[2], split[3],
29
                    Integer.parseInt(split[4]),
30
                    LocalDateTime.parse(split[5], DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
31
        }).toList();
32
        return userList;
33
    }
34
}

改造三：controller 注入 service（@Autowired）#

1
package com.itheima.controller;
2

3
import com.itheima.pojo.User;
4
import com.itheima.service.UserService;
5
import org.springframework.beans.factory.annotation.Autowired;
6
import org.springframework.web.bind.annotation.RequestMapping;
7
import org.springframework.web.bind.annotation.RestController;
8

9
import java.util.List;
10

11
@RestController
12
public class UserController {
13

14
    @Autowired   // 运行时由容器把 UserService 的对象送进来
15
    private UserService userService;
16

17
    @RequestMapping("/list")
18
    public List<User> list() {
19
        // 1. 调用 service，查询用户信息
20
        List<User> userList = userService.list();
21

22
        // 2. 响应数据
23
        return userList;
24
    }
25
}

改造前后对照#

改的只是三行代码，但性质完全变了：

一、知识回顾（读完直接做下面的实践题）#

1. 耦合：衡量软件中各个层/各个模块的依赖关联程度；内聚：软件中各个功能模块内部的功能联系；软件设计原则是 高内聚低耦合
2. 这个案例的耦合点、以及为什么算耦合：三处 new——controller 里 new UserServiceImpl()、service 里 new UserDaoImpl()；上层不但”用”下层的功能，还决定了下层”怎么出生”（具体用哪个实现类、什么时候创建），用哪个实现类是写死的，换实现就得改上层源码、重新编译
3. IOC（控制反转，Inversion Of Control）：对象的创建控制权由程序自身转移到外部（容器）
4. DI（依赖注入，Dependency Injection）：容器为应用程序提供运行时，所依赖的资源
5. Bean：IOC 容器中创建、管理的对象（比如 UserServiceImpl、UserDaoImpl）
6. 分层解耦的思路：① 将项目中的类交给 IOC 容器管理（IOC，控制反转）；② 应用程序运行时需要什么对象，直接依赖容器为其提供（DI，依赖注入）
7. 改造两件事：① 将 Dao 及 Service 层的实现类交给 IOC 容器管理；② 为 Controller 及 Service 注入运行时所依赖的对象
8. 两个注解怎么用：@Component 加在实现类上（不是接口上）——声明这个类交给容器管理；@Autowired 加在需要依赖的成员变量上——运行时由容器按类型找到对应的 bean 注入进来
9. 改造后的样子：三处 new 全部消失，变成”接口类型 + @Autowired”；对象由容器创建、依赖由容器注入；对外接口与响应完全不变（实测 /list 仍是 HTTP/1.1 200 + Content-Type: application/json）
10. bean 名字默认规则（实测）：由容器管理的 bean，名字默认为类名首字母小写——UserServiceImpl → userServiceImpl，UserDaoImpl → userDaoImpl（下一篇的 @Qualifier("userServiceImpl")、@Resource(name = ...) 用的就是它）

二、裸写题#

• 2-1 找出这几行代码里的耦合点 下面是一个三层架构工程的三个片段（都是改造前的写法）：

  1
  // 片段一
  2
  @RestController
  3
  public class UserController {
  4
      private UserService userService = new UserServiceImpl();
  5
      // ……
  6
  }
  7
  
  8
  // 片段二
  9
  public class UserServiceImpl implements UserService {
  10
      private UserDao userDao = new UserDaoImpl();
  11
      // ……
  12
  }

  请回答：

  1. 两个片段里，哪两行是”层与层耦合”的现场（原样抄出来）？
  2. 用”耦合/内聚”的话说，这两行为什么算耦合（说清”上层知道了什么不该它知道的事”）？
  3. 假设现在业务规则变了，新写了一个 UserServiceImpl2，想换掉原来的实现。改造前你要改哪些文件？改造后（把依赖交给容器）又要改哪些？把这个对比写出来。 （练习文件 test_38_找出耦合点.java 里给了写作区。）
  提示（先自己想，实在想不出再点开）

  一级 · 思路：盯住每个成员变量的等号右边——那是”具体用谁”的决定权；再想”这个决定权出现在哪一层”是不是合适 二级 · 方法：耦合点就是两处 new XxxImpl()；改造后这两行只剩”接口类型 + @Autowired”，具体实现由容器决定 三级 · 骨架：改造后应当长成 @____ private UserService userService; / @____ private UserDao userDao;

  参考答案（做完再点开）

  1. 两行耦合点（原样）：

     1
     private UserService userService = new UserServiceImpl();
     2
     private UserDao userDao = new UserDaoImpl();

  2. 为什么是耦合：成员变量的类型已经是接口了（UserService / UserDao），可等号右边把”具体用哪个实现类”也写死了——上层替下层做了”用谁、怎么创建”的决定。上层原本只需要知道”有这么一个能干活的接口”，现在却知道了下层的类名和构造方式；下层一换（或想换），上层的源码就得跟着改。这就是”依赖关联程度高”（耦合高）。
  3. 对比：

     	要改的地方
     改造前	要改 UserController 的源码（把 new UserServiceImpl() 换成 new UserServiceImpl2()），然后重新编译运行
     改造后（依赖交给容器）	上层代码不用动（只有接口类型 + @Autowired）；换成哪个实现由容器决定——在实现类上标 @Primary、或注入处用 @Qualifier / @Resource 指定（下一篇实测三招）

  一句话：改造前是”上层指哪打哪”，改造后是”上层提需求、容器给货”。

• 2-2 给三层加上 IOC/DI 改造 下面是一个能跑的三层工程（拆过层，但依赖全是自己 new 的）：

  1
  // dao 层实现类
  2
  public class UserDaoImpl implements UserDao {
  3
      @Override
  4
      public List<String> list() {
  5
          InputStream in = this.getClass().getClassLoader().getResourceAsStream("user.txt");
  6
          return IoUtil.readUtf8Lines(in, new ArrayList<>());
  7
      }
  8
  }

  1
  // service 层实现类
  2
  public class UserServiceImpl implements UserService {
  3
      private UserDao userDao = new UserDaoImpl();
  4
      @Override
  5
      public List<User> list() {
  6
          List<String> lines = userDao.list();
  7
          return lines.stream().map(line -> { /* 解析封装…… */ }).toList();
  8
      }
  9
  }

  1
  // controller
  2
  @RestController
  3
  public class UserController {
  4
      private UserService userService = new UserServiceImpl();
  5
      @RequestMapping("/list")
  6
      public List<User> list() {
  7
          return userService.list();
  8
      }
  9
  }

  要求（题面只说需求，两个注解的名字自己想）：

  1. 让数据访问层和业务逻辑层的实现类都交给容器管理（说明注解加在类的哪个位置）；
  2. 让控制层需要业务对象、业务层需要数据访问对象时，都不再自己创建，改由容器送进来；
  3. 在每处改动旁边写中文注释，说明”这一行原来是干什么的、现在谁来干”；
  4. 改造完在文件末尾回答：容器是在什么时候把依赖送进来的（启动时还是每次请求时）？改造后 UserController 里还剩几个 new？ （练习文件 test_38_分层解耦改造.java 里按 dao / service / controller 三块给了写作区。）
  提示（先自己想，实在想不出再点开）

  一级 · 思路：两件事分开做——“谁可以被容器创建”（在实现类上标一个注解）、“谁需要别人送我对象”（在成员变量上标一个注解） 二级 · 方法：把类交给容器用 @Component（加在实现类的 public class 上一行）；要依赖用 @Autowired（加在成员变量上一行）；成员变量只留”接口类型 + 名字”，等号右边整个删掉 三级 · 骨架：@____ public class UserDaoImpl implements UserDao { ... } / @____ private UserDao userDao; / @____ private UserService userService;

  参考答案（做完再点开）

  1
  // ============ dao 层实现类：交给容器 ============
  2
  @Component   // 原来没人管，现在交给 IOC 容器创建、管理（成为 bean）
  3
  public class UserDaoImpl implements UserDao {
  4
      @Override
  5
      public List<String> list() {
  6
          InputStream in = this.getClass().getClassLoader().getResourceAsStream("user.txt");
  7
          return IoUtil.readUtf8Lines(in, new ArrayList<>());
  8
      }
  9
  }

  1
  // ============ service 层实现类：交给容器 + 注入 dao ============
  2
  @Component   // 交给 IOC 容器管理
  3
  public class UserServiceImpl implements UserService {
  4
  
  5
      @Autowired   // 原来是自己 new UserDaoImpl()，现在由容器按类型找到 UserDaoImpl 的 bean 送进来
  6
      private UserDao userDao;
  7
  
  8
      @Override
  9
      public List<User> list() {
  10
          List<String> lines = userDao.list();
  11
          return lines.stream().map(line -> { /* 解析封装…… */ }).toList();
  12
      }
  13
  }

  1
  // ============ controller：注入 service ============
  2
  @RestController
  3
  public class UserController {
  4
  
  5
      @Autowired   // 原来是自己 new UserServiceImpl()，现在由容器注入
  6
      private UserService userService;
  7
  
  8
      @RequestMapping("/list")
  9
      public List<User> list() {
  10
          return userService.list();
  11
      }
  12
  }

  4. 两个回答：① 依赖是应用启动时由容器一次性准备好的（容器先把 UserDaoImpl、UserServiceImpl 创建成 bean，再把它们分别注入需要的地方；之后每次请求只是正常调用方法，不会再重新创建对象）；② 改造后 UserController 里 new 的数量是 0——这正是”控制反转”的直观标志。

• 2-3 改错题：三处改造没改对 小李照着步骤做分层解耦改造，写了下面三处代码，结果工程要么启动报错、要么运行起来空指针。请逐条指出错在哪、会出什么现象、怎么改：

  1
  // 第 ① 处
  2
  @Component
  3
  public interface UserDao {
  4
      public List<String> list();
  5
  }
  6
  
  7
  // 第 ② 处
  8
  public class UserDaoImpl implements UserDao {
  9
      @Override
  10
      public List<String> list() { /* ……照常读文件…… */ }
  11
  }
  12
  
  13
  // 第 ③ 处
  14
  public List<User> list() {
  15
      @Autowired
  16
      UserService userService;      // 写在方法里的局部变量上
  17
      return userService.list();
  18
  }

  显示更多显示更少

  （练习文件 test_38_改错题.java 里给了三处代码和写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：第 ① 处把注解加在了”不能创建对象的东西”上；第 ② 处少了让容器认领这个类的标记；第 ③ 处注解的位置超出了它管得着的范围 二级 · 方法：@Component 要加在实现类上（接口上加等于没加，容器造不出 bean）；@Autowired 要加在成员变量（或构造方法、setter 方法）上，不能标在方法体内的局部变量上 三级 · 骨架：@Component public class UserDao____ implements UserDao {...} / @Autowired private ____ userService;（放在类里，方法外面）

  参考答案（做完再点开）

  ① @Component 加在了接口上：接口不能被实例化，容器不会为它创建 bean。现象：上层注入 UserDao 类型时找不到可用的 bean，启动直接失败（报 No qualifying bean of type 'com.itheima.dao.UserDao' available 这一类错误）。改法：把注解挪到实现类上——

  1
  public interface UserDao { List<String> list(); }   // 接口不需要注解
  2
  
  3
  @Component
  4
  public class UserDaoImpl implements UserDao { ... } // 注解加在实现类上

  ② UserDaoImpl 漏了 @Component：这个类根本没交给容器，容器里没有它的 bean。现象和 ① 一样——注入时报”找不到类型为 UserDao 的 bean”（如果 service 里也还是 new UserDaoImpl()，那就是”改造没生效”，注入不生效的问题被掩盖了）。改法：在 UserDaoImpl 类上加 @Component。 ③ @Autowired 写在了方法体内的局部变量上：容器只认识”类里的成员”（成员变量、构造方法、setter 方法），管不到方法执行到那一行时的局部变量。现象：注解完全无效，userService 是 null，调用 userService.list() 时抛 NullPointerException。改法：把依赖声明成成员变量，注解也标在成员变量上——

  1
  @RestController
  2
  public class UserController {
  3
  
  4
      @Autowired                 // 成员变量上（类里、方法外）
  5
      private UserService userService;
  6
  
  7
      @RequestMapping("/list")
  8
      public List<User> list() {
  9
          return userService.list();
  10
      }
  11
  }

三、综合题#

• 3-1 给三层架构案例加上 IOC/DI 改造 在上一篇（37 篇）拆好三层的工程上继续做，每一步都保留”能跑”的状态：

  1. 先跑一次 curl -si http://localhost:8080/list，把改造前的状态码与 Content-Type 抄下来（作为基准）；
  2. 给 dao 层实现类加 @Component，交出创建权；
  3. 把 service 层的 private UserDao userDao = new UserDaoImpl(); 改成”接口类型 + @Autowired”，并在实现类上补 @Component；
  4. 把 controller 里的 private UserService userService = new UserServiceImpl(); 改成”接口类型 + @Autowired”；
  5. 重启后做三件事：curl -si .../list 看状态码与 Content-Type、浏览器打开 user.html 看表格、在启动日志/断点里确认对象是容器给的（不是 null）；
  6. 记录对照：改造前后各改了几个文件、new 从几处变成几处、对外响应有没有变；
  7. 再练一次”换实现”：新建 UserServiceImpl2（实现同一个接口，把返回的 id 都加 200），类上也标 @Component，重启后观察接口返回的 id——如果启动直接失败，把报错抄到练习文件末尾（这个报错正是下一篇要处理的问题）。 （练习文件 test_38_综合_IOC-DI改造.java 里按这 7 步给了写作区。）

  涉及知识点

  知识点	在这里的应用
  耦合/内聚	三处 new 是耦合点；把创建权交出去降低耦合
  IOC	实现类上加 @Component，对象由容器创建
  DI	成员变量上加 @Autowired，容器运行时注入
  Bean	被容器创建/管理的 UserDaoImpl、UserServiceImpl 都成了 bean
  接口与实现	成员变量类型仍是接口，实现由容器决定
  重构验证	对外接口与响应与改造前一致

  提示（先自己想，实在想不出再点开）

  一级 · 思路：改造永远从最底层往上做（先 dao、再 service、最后 controller），每改一层就把依赖它的那一层跟着改掉 new 二级 · 方法：实现类加 @Component；需要依赖的成员变量改成 @Autowired + 接口类型（删掉等号右边）；验证照旧用 curl -si（看头）和浏览器（看页面） 三级 · 骨架：@____ public class UserServiceImpl implements UserService { @____ private UserDao userDao; ... } / 换实现后的报错关键词 = required a single bean, but 2 were found

  参考答案（做完再点开）

  3-1 分步结果：

  1. 改造前基准（本机实测值，最终代码工程也是这个数）：

     1
     HTTP/1.1 200
     2
     Content-Type: application/json
     3
     Transfer-Encoding: chunked

  2. @Component public class UserDaoImpl implements UserDao { ... }

  3. 1
     @Component
     2
     public class UserServiceImpl implements UserService {
     3
         @Autowired
     4
         private UserDao userDao;
     5
         // ……
     6
     }

  4. 1
     @RestController
     2
     public class UserController {
     3
         @Autowired
     4
         private UserService userService;
     5
         // ……
     6
     }

  5. 三项验证：/list 仍是 200 + application/json；user.html 表格仍是 8 行；userService、userDao 都不是 null（能被容器注入，说明它们确实是 bean）。
  6. 对照表：

     	改造前	改造后
     改动文件	—	3 个（UserDaoImpl、UserServiceImpl、UserController）
     new 的处数	2	0
     对外响应	200 + application/json	完全一样

  7. 换实现的结果：新增第二个实现类后启动会失败，报错大意是——

     1
     Field userService in com.itheima.controller.UserController required a single bean, but 2 were found:
     2
         - userServiceImpl: defined in URL [...]
     3
         - userServiceImpl2: defined in URL [...]

     这是 @Autowired 默认按类型注入遇到”同类型两个 bean”时的正常反应——本机实测的完整日志见下一篇，那里会给三个解决方案（@Primary / @Qualifier / @Resource）。