互聯(lián)網(wǎng)/程序員/技術(shù)/資料共享?
來自：toutiao.com/i6882356844245975563
前幾天刷頭條又刷到了「Service層和Dao層真的有必要每個類都加上接口嗎？」這個問題，之前簡單回答了一波，給出的觀點(diǎn)是「看情況」現(xiàn)在結(jié)合我參與的項(xiàng)目以及閱讀的一些項(xiàng)目源碼來看。如果項(xiàng)目中使用了像Spring這樣的依賴注入框架，那可以不用接口！先來說說為什么使用了依賴注入框架以后，可以不使用接口！我整理了支持Service層和Dao層需要加上接口的理由，總結(jié)下來就這么三個：可以在尚未實(shí)現(xiàn)具體Service邏輯的情況下編寫上層代碼，如Controller對Service的調(diào)用
Spring默認(rèn)是基于動態(tài)代理實(shí)現(xiàn)AOP的，動態(tài)代理需要接口
可以對Service進(jìn)行多實(shí)現(xiàn)
先說說第一個理由：「上層可以在下層邏輯沒有實(shí)現(xiàn)的情況下進(jìn)行編碼」！很典型的面向接口編程，對層與層之間進(jìn)行了解耦，看起來好像沒有問題。這種開發(fā)方式適合不同模塊之間是由不同的人或項(xiàng)目組開發(fā)的，因?yàn)闇贤ǖ某杀颈容^大。同時避免由于項(xiàng)目組之間開發(fā)進(jìn)度的差異而相互影響。不過讓我們回想一下，在一般項(xiàng)目開發(fā)里面，有多少項(xiàng)目組是按層來切分開發(fā)任務(wù)的呢？實(shí)際上，大部分的項(xiàng)目都是按照功能劃分的。即使是現(xiàn)在前后端分離的情況，單純的后端開發(fā)也是按照功能模塊進(jìn)行任務(wù)劃分，即一個人負(fù)責(zé)從Controller層到DAO層的完整邏輯處理。在這種情況下，每一層都先定義一個接口，再去實(shí)現(xiàn)邏輯，除了增加了開發(fā)人員的工作量（當(dāng)然，如果代碼量計(jì)入工作量的話，那開發(fā)人員應(yīng)該也不是太排斥接口的?。?，實(shí)際沒有任何用處。如果開發(fā)人員想在下層邏輯沒有完成的情況下，先開發(fā)上層邏輯，可以先編寫下層類的空方法來先完成上層的邏輯。這里推薦一個個人比較喜歡的開發(fā)流程，自上向下的編碼流程：先在Controller層編寫邏輯，遇到需要委托Service調(diào)用的地方，直接先寫出調(diào)用代碼。
優(yōu)先完成Controller層的流程
然后使用IDE的自動補(bǔ)全，對剛才調(diào)用下層的代碼生成對應(yīng)的類和方法，在里面添加TODO
等所有的類和方法都補(bǔ)全了，再基于TODO，按照上面的流程去一個個的完善邏輯。
此方法可以使你對業(yè)務(wù)流程有比較好的理解。
對于第二個理由，就完全不成立了。Spring默認(rèn)是基于動態(tài)代理的，不過通過配置是可以使用CGLib來實(shí)現(xiàn)AOP。CGLib是不需要接口的。最后一個理由是「可以對Service進(jìn)行多實(shí)現(xiàn)」。這個理由不充分，或者說沒有考慮場景。實(shí)際上在大多數(shù)情況下是不需要多實(shí)現(xiàn)，或者說可以使用其它方式替代基于接口的多實(shí)現(xiàn)。另外，對于很多使用了接口的項(xiàng)目，項(xiàng)目結(jié)構(gòu)也是有待商榷的！下面，我們結(jié)合項(xiàng)目結(jié)構(gòu)來說明。一般項(xiàng)目結(jié)構(gòu)都是按層來劃分的，如下所示：對于不需要多實(shí)現(xiàn)的情況，也就不需要接口了。上面的項(xiàng)目結(jié)構(gòu)即可滿足要求。對于需要多實(shí)現(xiàn)的情況，無論是現(xiàn)在需要，還是后面需要。這種情況下，看起來好像是需要接口。此時的項(xiàng)目結(jié)構(gòu)看起來像這樣：- impl ---?實(shí)現(xiàn)在另一個包里
對于上面的結(jié)構(gòu)，我們來考慮多實(shí)現(xiàn)的情況下，該怎么處理？第一種方式，是在Service中新增一個包，在里面編寫新的邏輯，然后修改配置文件，將新實(shí)現(xiàn)作為注入對象。第二種方式，是新增一個Service模塊，在里面編寫新的邏輯（注意這里的包和原來Service的包不能相同，或者包相同，但是類名不同，否則無法創(chuàng)建類。因?yàn)樵诩虞d時需要同時加載兩個Service模塊，如果包名和類名都相同，兩個模塊的類全限定名就是一樣的了?。缓笮薷呐渲梦募?，將新邏輯作為注入對象。Controller
Service
Service2
Dao
相對而言，實(shí)際第一種方式相對更簡單一點(diǎn)，只需要關(guān)注包層面。而第二種方式需要關(guān)注模塊和包兩個層面。另外，實(shí)際這兩種方式都導(dǎo)致了項(xiàng)目中包含了不需要的邏輯代碼。因?yàn)槔线壿嫸紩淮蜻M(jìn)包里。不過，從結(jié)構(gòu)上來看，實(shí)際方式二的結(jié)構(gòu)要比方式一的結(jié)構(gòu)更清晰，因?yàn)閺哪K上能區(qū)分邏輯。那有沒有辦法來結(jié)合兩者的優(yōu)點(diǎn)呢？答案是肯定的，而且操作起來也不復(fù)雜！首先將接口和實(shí)現(xiàn)獨(dú)立開，作為一個獨(dú)立的模塊：Controller
Service --- 接口模塊
ServiceImpl2
Dao
其次，調(diào)整打包配置，ServiceImpl和ServiceImpl2二選一。既然ServiceImpl和ServiceImpl2是二選一，那ServiceImpl和ServiceImpl2的包結(jié)構(gòu)就可以相同。包結(jié)構(gòu)相同了，那調(diào)整了依賴以后，依賴注入相關(guān)的配置就不需要調(diào)整了。調(diào)整后，項(xiàng)目結(jié)構(gòu)看起來像這樣：Controller
Service --- 接口模塊
ServiceImpl2
Dao
現(xiàn)在，ServiceImpl和ServiceImpl2模塊中的包結(jié)構(gòu)、類名都是一樣的。那我們還需要接口模塊嗎？假設(shè)，我們把Service接口模塊去掉，結(jié)構(gòu)變成了如下所示：- Service1 --- 老實(shí)現(xiàn)
- Service2 --- 新實(shí)現(xiàn)
單純的通過調(diào)整模塊依賴，是否能實(shí)現(xiàn)Service的多實(shí)現(xiàn)？答案顯而易見吧？上面給出了不使用接口的理由。不過不使用接口并不是完全沒有缺點(diǎn)的，主要問題就是在進(jìn)行多實(shí)現(xiàn)的時候，沒有一個強(qiáng)接口規(guī)范。即不能通過實(shí)現(xiàn)接口，借助IDE快速生成框架代碼。對于沒有實(shí)現(xiàn)的接口，IDE也能給出錯誤提醒。一個不太優(yōu)雅的解決是，將原來的模塊里的代碼拷貝一份到新模塊中，基于老代碼來實(shí)現(xiàn)新的邏輯。所以，如果一個項(xiàng)目需要多實(shí)現(xiàn)、且多實(shí)現(xiàn)數(shù)量較多（不過一般項(xiàng)目不會有多個實(shí)現(xiàn)的），則推薦使用接口。否則不需要使用接口。本文針對「Service層是否需要接口」這個問題，指出需要接口的理由的問題。以及個人對這個問題的觀點(diǎn)，希望在評論區(qū)寫出自己的理解 ！推薦閱讀：
校招毀約污點(diǎn)公司名錄.pdf
Intellij IDEA 竟然把 Java8 的數(shù)據(jù)流問題這么完美的解決掉了！
5T技術(shù)資源大放送！包括但不限于：C/C++，Linux，Python，Java，PHP，人工智能，單片機(jī)，樹莓派，等等。在公眾號內(nèi)回復(fù)「2048」，即可免費(fèi)獲取??！微信掃描二維碼，關(guān)注我的公眾號
朕已閱?
