在藉助Spring Boot框架開發web項目時，在業務層（Service）這一部分，標準做法是：定義一個接口，然後再一個或多個類去實現。那麼疑問來了：
爲什麼我們要維護兩份同構代碼，而不直接使用一個類呢？
不創建接口，通過把業務實現類直接通過註解@Autowired注入控制層Controller，也一點不耽誤功能的實現啊，那麼我爲什麼還要創建接口？
網上大部分回答都是說什麼面向對象的解耦云云，引經據典，說得都很好，然而，都沒有從根本上回答我們關心的問題：爲什麼要用接口？
業務層（Service）中爲什麼一定要用接口，不用行不行？回答：不是必須要使用接口，但強烈建議使用接口。
情景1: 在開源框架中有很多這種情況,就是某個功能支持用戶自定義擴展.說白了,它提供了一個接口,我們只需要實現這個接口,把我們自己的實現邏輯補上,就可以讓框架按照我們的邏輯來執行.問題來了,框架的作者並不知道我們的實現類是什麼,如果不定義一個接口,那麼要如何在框架中調用我們的實現類呢?
情景2: 我和同事分別做項目的2個不同功能模塊,但是同事的功能中卻需要調用我這頭實現的部分邏輯.爲了讓他有一個"佔位符"可用,我是不是應該快速的寫個接口扔給他呢?
情景3: 一個適配器功能,或是說一個簡單的工廠類,如果沒有定義接口,那麼面對衆多實現類,要如何統一操作呢?
情景4: 想讓項目的代碼符合某種"規範",但是又不可能看着別人寫代碼吧,那好辦,先出一套接口,然後你們就看着辦~
情景5: java中沒有多繼承,但是可以多實現接口,那麼就有一件很有趣的事情了,一個實現類可以實現多個接口,然後此時接口可以有選擇的暴露實現類的部分方法,做到"窄化"實現類功能的目的。
當然例子還有很多，這些情況其實可以說是接口好處的體現,所以java有面向接口編程的建議，但是說回Service層一定要有接口嗎?那到未必，因爲說到底,多一個接口僅僅是擴展性和某些情況下有優勢,但是是否會用到接口的便利性，不確定的情況下我們未必一定要爲"可能"買單，只是多寫那幾行代碼，付出一點就可能避免"未來"的大"煩擾",何樂而不爲!?
下面簡單列出Spring Boot中業務層（Service）的創建步驟及應用：
1）接口及實現類命名方式，接口XXXService，實現類：XXXServiceImpl。
2）實現類XXXServiceImpl需添加註解@Service，並指明名稱，如@Service("companyService")；
3）在實現類中，通過註解@Autowired，注入數據倉庫層Repository接口；
當實現的接口涉及數據庫數據的刪除或修改時，方法上一定要添加註解@Transactional，否則會執行不成功。
更加詳細的可參見我的視頻：https://edu.51cto.com/sd/091c7