Service層和Dao層真的有必要每個類都加上接口嗎?

近在嘗試寫一個基於spring mvc的基礎框架,這個問題想了很久了,有接口的時候我維護起來並沒有感覺會有多方便。請各位解答一下謝謝!
10 個回答
架构思维
2019-07-16

簡單來說就是看情況。

主要看你項目:

  • 變動情況
  • 以及架構
  • 人員
  • 項目情況

比如,項目原來使用的hibernate,後續可能要切換為mybatis,那麼dao就需要使用接口。這就不會影響上層代碼的修改。

再比如,項目是個單體應用,任何代碼的修改都需要重新編譯整個項目,那可以不用接口。而如果項目是分模塊編譯部署的,那就可以使用接口解耦,假設dao有修改,只需要重新編譯部署dao模塊即可,不影響上層模塊。

再來,如果項目組新手較多,可能簡單的代碼結構更適合。複雜項目結構的學習成本要高。

假如,項目進度很急,可以使用簡單粗暴的方式先擼~

可以用經濟學上的成本來解釋原因。

經濟學上的成本定義是:你做一件事,所放棄的其它事情中,價值最大的那件事的價值就是你做這件事的成本。

你使用接口的成本就是你不使用接口所花費的成本(包括後續的維護成本)。

如果項目變動多、模塊部署、項目不急,那使用接口的成本就低於不使用接口的成本,雖然早期可能不用接口看起來更簡單;反之,則不用接口的成本低,甚至框架都可以不使用~

畢竟工具是為了提高效率的,何必和自己過不去呢!

Shooray
2019-07-17

你反思說明你開啟智商了。我也曾問過很多程序員包括自己,為什麼每寫一個類都要找寫一個接口,再寫一個實現類Impl?竟然沒有一個程序員能正確回答,大部分都竟然說老師或者書上都這麼教的,而且學spring框架都這麼幹。前面有人也回覆了接口是穩定的,實現類不穩定,經常要改。但一般代碼都是你自己寫的,穩不穩定自己不清楚嗎?如果一定要改,連接口一起改豈不是更費勁。所以往深層次思考,連spring框架都要去質疑了。

所以我的結論是,國內的開發習慣導致了這個疑問。因為作為團隊開發來講,規範的開發習慣是先寫接口和測試用例,實現類甚至會寫一個偽代碼以保證測試代碼能正確運行。測試驅動的軟件開發是一定要實現和接口分離的,從J2EE到Spring架構的演化都是遵循這個目標。

現實是一個程序員自己搞定好幾層,然後沒有一行測試代碼。這種情況下每個類都寫一個接口再寫一個實現類,豈不是畫蛇添足嗎!

這是我的見解,歡迎拍磚。

lsong98sh
2019-07-16

接口不是為了替換實現。如果從mysql改成Oracle,只要把方法內容改變即可。不改變方法聲明就行。做接口,是為了共存。接口往往都會和工廠模式一起用。比如,發送代辦,可以做一個send的接口。這樣可以有多個實現類。比如短信,郵件,微信,釘釘等。至於service和dao是否需要接口,我覺得如果是做產品,則需要接口。定製時,只要通過繼承原實現類並重寫方法實現。否則定製只能通過修改源代碼實現。至於修改了某個類的方法導致1000個調用了此方法的類要重編譯,那要看是否修改了方法聲明。即便使用接口,接口申明改了也要全部編譯的。只要不是產品,或者通用組件,純業務上的service和dao沒有太大必要使用接口。日誌,代辦,消息等通用服務組件上使用接口還是有必要的。當然使用了接口,在轉變為微服務上,成本會小很多。通過接口代理,可以實現該業務實現類在不同的架構上的重用。

saizone
2019-07-16

用接口是為了以後換業務邏輯和數據訪問方便維護和擴展。這是面向對象的編程思想-多態。

剛開始寫的時候,你會感覺會多寫了一個接口文件,沒什麼用。但是當你代碼越來越多時,如果你調用的不是接口,而是具體的類。需要更改時,你只能有兩種做法,一是重構所有調用代碼裡的類名,二是選擇直接修改原有的service或dao。在項目複雜的情況下這兩種做法都更容易出錯。你可以想象一下如果有1000個方法調用某個dao的class,當你需要把dao從mysql換到oracle的時候,你需要改1000個方法裡的調用的類名。

如果你調用的地方是接口,那無需改方法裡對象變量的類型。你只需要寫新的service或dao的impl,亦或者新的service和dao繼承舊的,只重寫部分方法。用的時候只需要通過注入就可以讓所有調用service或dao的接口使用新的實現類或方法。

过客看客过8848
2019-07-16

接口分離原則(ISP),是面向對象方法學一個非常重要的原則,接口是穩定的,接口的具體實現是易變的,上層組件不要直接依賴於下層組件,而是要上層組件和下層組件通過接口實現依賴,上層組件以聚合關聯接口,下層組件以泛化實現接口,從而實現面向對象方法學的另一個重要原則——依賴反轉原則(DIP),這樣下層組件的改變不會影響上層組件。只對接口編程,不要對具體實現編程。比如下層DAO使用的ORM由hibernate換成mybatis,上層Service組件不變;再比如JDBC編程都是以接口方式進行,而數據庫的變化和JDBC驅動的變化不會影響我們的上層代碼。

杨中科
2019-07-16

如果只是簡單的項目,是看不出接口編程的好處的,甚至更麻煩,還不如不用接口直接調用實現類更省事。但是如果項目比較複雜,基於接口編程的好處就很大了,就可以“不依賴於實現類”了。比如可以注入一個實現了接口mock實現類以便於各模塊獨立測試;比如可以注入一個動態代理實現類,雖然最終還是由動態代理實現類調用實際實現類,但是可以在中間插入緩存處理、權限控制、rpc等,而這一切對於接口的使用者來講是透明的,他只要聲明一下“我要一個實現了A接口的類對象”即可,其他都有框架處理。

上淋829
2019-07-16

你是做研發的還是做設計的。研發的同學一般看到接口都是qnmlgb的接口。你是做設計的話,一般都不知道怎麼實現。接口和類的區別就是一個字抽象,架構裡邊有兩個很重要的原則,一個是穩定依賴原則,另一個是穩定抽象原則,代表的是依賴的模塊要是穩定的,抽象的模塊代表穩定,最終抓換成依賴抽象。因此如果你能預見你的系統的所有功能,且有限,你可以不抽象。否則就還是抽象吧,這不會錯,也不會花你更多的時間

广云时代
2019-07-17

服務端內類的調用使用接口對於一般應用場景來說,意義不大。

對於大型軟件,分層較多,模塊之間需要團隊協作,或者上下層之間調用,使用接口對於提供方和調用方可以同步開發,提供效率。

但如今的代碼架構,大多數都是客戶端APP+API的方式,所謂的API其實就相當於接口,類的接口就比較多餘了。有的拿設計模式說事,認為基於接口可以不依賴實現,有利於鬆耦合,我寫了多年代碼,也就是第三方登錄,第三方支付等說得出的這幾個地方用的上有實用意義的接口,一般的業務代碼哪有那麼多種不同的實現。

基於接口,還有一點意義就是可以用依賴注入容器創建實現類。但是在C#,不需要接口也可以直接把注入容器,Java我不熟悉不知道可不可以。

總的來說我認為有用的地方不多,不用也罷。

沐紫剑
2019-07-17

我說一種場景,service接口99%都只有一個實現類,而且使用都是基於註解的方式,也就是說如果之前沒有定義接口,後來需要時重構一下就可以,不需要改變調用的地方,這種情況下為什麼還要非得每個service都弄個接口呢,除了教條主義還有什麼能解釋的?

hao947
2019-07-16

問這個的都是思維死板。誰告訴你,一定有service,dao。程序,想怎麼寫就怎麼寫,約束那玩意,看心情不好。

相關推薦

推薦中...