为解决移植性问题而产生的套路
2005年以前的大多数项目都是直接在业务处理层的Service类中嵌入JDBC代码，这就使得这个Service类与数据库紧藕合，在换一种数据库的情况下，就要修改Service类中的sql。 根据软件设计的开闭原则，软件应该对修改关闭、对扩展开放。 因此，那时聪明的程序员就把这个Service类设计成一个接口，使控制层只依赖这个接口，于是就有了controller+service+serviceImpl；这样，当某天这个应用要跑在其它数据库上时，就而只需要增加一个serviceImpl类。 这就是service+serviceImpl套路产生的背景。

如果该Service有多个实现类，如何设置注入哪个ServiceImpl类

接口

public interface HumanService {
    public String name();
}

接口实现类

 
@Service("teacherService")
public class TeacherServiceImpl implements HumanService {
    @Override
    public String name() {
        System.out.println("teacher");
        return "teacher";
    }
}
 
@Service("doctorService")
public class DoctorServiceImpl implements HumanService {
    @Override
    public String name() {
        System.out.println("doctor");
        return "doctor";
    }
}

控制器

@RestController
public class HumanController {
//    @Resource(name="doctorService")
    @Autowired
    @Qualifier("teacherService")
    private HumanService humanService;
 
    @RequestMapping("/name")
    public String name(){
        return humanService.name();
    }
}