作者:架構思維
前幾天刷頭條又刷到了「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也能給出錯誤提醒。