前幾天刷頭條又刷到了「Service層和Dao層真的有必要每個類都加上介面嗎？」這個問題，之前簡單回答了一波，給出的觀點是「看情況」！
現在結合我參與的專案以及閱讀的一些專案原始碼來看。如果
專案中使用了像Spring這樣的依賴注入框架，那可以不用介面
！
先來說說為什麼使用了依賴注入框架以後，可以不使用介面！
不需要介面的理由
我整理了支援Service層和Dao層需要加上介面的理由，總結下來就這麼三個：
可以在尚未實現具體Service邏輯的情況下編寫上層程式碼，如Controller對Service的呼叫
Spring預設是基於動態代理實現AOP的，動態代理需要介面
可以對Service進行多實現
實際上，這三個理由都站不住腳！
先說說第一個理由：「上層可以在下層邏輯沒有實現的情況下進行編碼」！很典型的面向介面程式設計，對層與層之間進行了解耦，看起來好像沒有問題。
這種開發方式適合不同模組之間是由不同的人或專案組開發的，因為溝通的成本比較大。同時避免由於專案組之間開發進度的差異而相互影響。
不過讓我們回想一下，在一般專案開發裡面，有多少專案組是按層來切分開發任務的呢？實際上，大部分的專案都是按照功能劃分的。即使是現在前後端分離的情況，單純的後端開發也是按照功能模組進行任務劃分，即一個人負責從Controller層到DAO層的完整邏輯處理。在這種情況下，每一層都先定義一個介面，再去實現邏輯，除了增加了開發人員的工作量（當然，如果程式碼量計入工作量的話，那開發人員應該也不是太排斥介面的！），實際沒有任何用處。
如果開發人員想在下層邏輯沒有完成的情況下，先開發上層邏輯，可以先編寫下層類的空方法來先完成上層的邏輯。
這裡推薦一個個人比較喜歡的開發流程，自上向下的編碼流程：
先在Controller層編寫邏輯，遇到需要委託Service呼叫的地方，直接先寫出呼叫程式碼。優先完成Controller層的流程
然後使用IDE的自動補全，對剛才呼叫下層的程式碼生成對應的類和方法，在裡面新增TODO
等所有的類和方法都補全了，再基於TODO，按照上面的流程去一個個的完善邏輯。
此方法可以使你對業務流程有比較好的理解。
對於第二個理由，就完全不成立了。Spring預設是基於動態代理的，不過透過配置是可以使用CGLib來實現AOP。CGLib是不需要介面的。
最後一個理由是「可以對Service進行多實現」。這個理由不充分，或者說沒有考慮場景。實際上在大多數情況下是不需要多實現，或者說可以使用其它方式替代基於介面的多實現。
另外，對於很多使用了介面的專案，專案結構也是有待商榷的！下面，我們結合專案結構來說明。
專案結構與介面實現
一般專案結構都是按層來劃分的，如下所示：
Controller
Service
Dao
對於不需要多實現的情況，也就不需要介面了。上面的專案結構即可滿足要求。
對於需要多實現的情況，無論是現在需要，還是後面需要。這種情況下，看起來好像是需要介面。此時的專案結構看起來像這樣：
Controller
Service
——介面在一個包中
impl ——-實現在另一個包裡
Dao
對於上面的結構，我們來考慮多實現的情況下，該怎麼處理？
第一種方式，是在Service中新增一個包，在裡面編寫新的邏輯，然後修改配置檔案，將新實現作為注入物件。
Controller
Service
—— 介面在一個包中
impl ——-實現在另一個包裡
impl2 ——-新實現在另一個包裡
Dao
第二種方式，是新增一個Service模組，在裡面編寫新的邏輯（注意這裡的包和原來Service的包不能相同，或者包相同，但是類名不同，否則無法建立類。因為在載入時需要同時載入兩個Service模組，如果包名和類名都相同，兩個模組的類全限定名就是一樣的了！），然後修改配置檔案，將新邏輯作為注入物件。
Controller
Service
—— 介面在一個包中
impl ——-實現在另一個包裡
Service2
impl2 ——-新實現在另一個包裡
Dao
相對而言，實際第一種方式相對更簡單一點，只需要關注包層面。而第二種方式需要關注模組和包兩個層面。另外，實際這兩種方式都導致了專案中包含了不需要的邏輯程式碼。因為老邏輯都會被打進包裡。
不過，從結構上來看，實際方式二的結構要比方式一的結構更清晰，因為從模組上能區分邏輯。
那有沒有辦法來結合兩者的優點呢？答案是肯定的，而且操作起來也不復雜！
首先將介面和實現獨立開，作為一個獨立的模組：
Controller
Service ——- 介面模組
ServiceImpl
impl ——-實現在另一個包裡
ServiceImpl2
impl2 ——-新實現在另一個包裡
Dao
其次，調整打包配置，ServiceImpl和ServiceImpl2二選一。既然ServiceImpl和ServiceImpl2是二選一，那ServiceImpl和ServiceImpl2的包結構就可以相同。包結構相同了，那調整了依賴以後，依賴注入相關的配置就不需要調整了。調整後，專案結構看起來像這樣：
Controller
Service ——- 介面模組
ServiceImpl
impl ——-實現在另一個包
ServiceImpl2
impl ——-新實現和老實現在相同的包中
Dao
現在，ServiceImpl和ServiceImpl2模組中的包結構、類名都是一樣的。那我們還需要介面模組嗎？
假設，我們把Service介面模組去掉，結構變成了如下所示：
Controller
Service1 ——- 老實現
Service2 ——- 新實現
Dao
單純的透過調整模組依賴，是否能實現Service的多實現？答案顯而易見吧？
不使用介面的缺點
上面給出了不使用介面的理由。不過不使用介面並不是完全沒有缺點的，主要問題就是在進行多實現的時候，沒有一個強介面規範。即不能透過實現介面，藉助IDE快速生成框架程式碼。對於沒有實現的介面，IDE也能給出錯誤提醒。
一個不太優雅的解決是，將原來的模組裡的程式碼複製一份到新模組中，基於老程式碼來實現新的邏輯。
所以，如果一個專案需要多實現、且多實現數量較多（不過一般專案不會有多個實現的），則推薦使用介面。否則不需要使用介面。
總結
本文針對「Service層是否需要介面」這個問題，指出需要介面的理由的問題。以及個人對這個問題的觀點，希望對大家有一些幫助。
