SpringbootではなぜServices+ServiceImplの構造を採用する必要があるのですか?

移植性の問題を解決するためのアプローチ2005年以前のほとんどのプロジェクトは,業務処理層のサービスクラスにJDBCコードを直接埋め込むことで,このサービスクラスがデータベースと連携し,データベースを交換する場合にはサービスクラスのsqlを修正する.ソフトウェア設計の開閉原則に基づいて、ソフトウェアは修正に対して閉じ、拡張に対して開放しなければならない.そのため、その時賢いプログラマーはこのサービスクラスをインタフェースに設計し、制御層をこのインタフェースに依存させ、controller+service+serviceImplを持っていた.このように、ある日、このアプリケーションが他のデータベース上に実行されると、serviceImplクラスを1つ追加するだけです.これがサービス+サービスインプラントの背景です.
サービスに複数のインプリメンテーションクラスがある場合、どのサービスインプリメンテーションクラスを注入するかを設定する方法

  
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();
    }
}