簡單來說就是看情況。
主要看你項目：
比如，項目原來使用的hibernate，后續可能要切換為mybatis，那么dao就需要使用接口。這就不會影響上層代碼的修改。
再比如，項目是個單體應用，任何代碼的修改都需要重新編譯整個項目，那可以不用接口。而如果項目是分模塊編譯部署的，那就可以使用接口解耦，假設dao有修改，只需要重新編譯部署dao模塊即可，不影響上層模塊。
再來，如果項目組新手較多，可能簡單的代碼結構更適合。復雜項目結構的學習成本要高。
假如，項目進度很急，可以使用簡單粗暴的方式先擼～
可以用經濟學上的成本來解釋原因。
經濟學上的成本定義是：你做一件事，所放棄的其它事情中，價值最大的那件事的價值就是你做這件事的成本。
你使用接口的成本就是你不使用接口所花費的成本（包括后續的維護成本）。
如果項目變動多、模塊部署、項目不急，那使用接口的成本就低于不使用接口的成本，雖然早期可能不用接口看起來更簡單；反之，則不用接口的成本低，甚至框架都可以不使用～
畢竟工具是為了提高效率的，何必和自己過不去呢！
你反思說明你開啟智商了。我也曾問過很多程序員包括自己，為什么每寫一個類都要找寫一個接口，再寫一個實現類Impl？竟然沒有一個程序員能正確回答，大部分都竟然說老師或者書上都這么教的，而且學spring框架都這么干。前面有人也回復了接口是穩定的，實現類不穩定，經常要改。但一般代碼都是你自己寫的，穩不穩定自己不清楚嗎？如果一定要改，連接口一起改豈不是更費勁。所以往深層次思考，連spring框架都要去質疑了。
所以我的結論是，國內的開發習慣導致了這個疑問。因為作為團隊開發來講，規范的開發習慣是先寫接口和測試用例，實現類甚至會寫一個偽代碼以保證測試代碼能正確運行。測試驅動的軟件開發是一定要實現和接口分離的，從J2EE到Spring架構的演化都是遵循這個目標。
現實是一個程序員自己搞定好幾層，然后沒有一行測試代碼。這種情況下每個類都寫一個接口再寫一個實現類，豈不是畫蛇添足嗎！
這是我的見解，歡迎拍磚。
是早期Spring的鍋，早期沒有cglib，只有Jdk的動態，不這么寫就無法實現切面相關的功能。。。。后來改cglib就沒有這種強制要求了，但是這種習慣卻被很多人延續了
如果只是簡單的項目，是看不出接口編程的好處的，甚至更麻煩，還不如不用接口直接調用實現類更省事。但是如果項目比較復雜，基于接口編程的好處就很大了，就可以“不依賴于實現類”了。比如可以注入一個實現了接口mock實現類以便于各模塊獨立測試；比如可以注入一個動態代理實現類，雖然最終還是由動態代理實現類調用實際實現類，但是可以在中間插入緩存處理、權限控制、rpc等，而這一切對于接口的使用者來講是透明的，他只要聲明一下“我要一個實現了A接口的類對象”即可，其他都有框架處理。
這個問題是一個非常好的問題，很多程序員在剛開始工作的時候，接觸到的項目都是這樣做的，一個接口對應一個實現類，然后就一直保持了這個習慣，但是可能并沒有考慮過為什么要這么做，或者并沒有想過這么做的好處是什么。
從工程化的角度來看，面向接口的編程是很有必要的，不過我們還是要結合實際情況來考慮。
這句話看起來是沒有問題的，比如我們要實現一個給用戶發送短信的功能：
項目剛開始的時候，公司買了阿里云的服務，直接調用阿里云的一個接口進行短信發送；項目運行一段時間，又改成和騰訊云合作，那么發送短信的代碼就需要修改；為了避免領導說“再改回去吧”，這里寫一個接口、兩個實現，上層方法只面向接口編寫，就會方便很多。
不過，這一切都是我們“假想”出來的，至少我工作十多年，幾乎沒見過這種變來變去的需求，至于 Dao 層都加接口，避免項目做數據庫遷移，原來用 Oracle 現在要換成 MySQL 之類的... 從來沒有遇到過。
這句話沒有錯，通常這種情況確實適合使用面向接口的編程，比如 JDBC 的實現：
Oracle 公司（之前的 Sun）提供 JDBC 標準（接口）。
各個數據庫廠商提供針對自家數據庫的實現。
我等碼農在 Java 中敲代碼訪問數據庫。
這時候接口制定、接口實現和接口使用就是不同的人；
但是如果在同一個項目中呢？
如果項目是一個人開發的，那不用說，接口制定、實現和使用都是一個人，這時候還費這勁兒干啥；
我們大多數項目，接口類和實現類都是一個人來做的，很少有項目是領導把接口寫好，然后說“各位小弟，實現類就看你們的了”；
那么實現和使用的人呢？大部分時候也是同一個人，但也有例外，比如一個需求設計兩個功能模塊的修改，A 模塊的開發要用 B 模塊的一個功能，這時候可以 B 模塊的開發把接口先定好，這樣 A 和 B 就可以同時開發了；
當然 B 模塊的開發也可以先寫一個空方法：方法名稱、入參和出參都制定好，中間沒有邏輯，然后先提交一版，這樣 A 模塊的開發就可以快樂地 new() 了；不過我不太建議這樣做的原因是：通常開發 commit 一次，提交的內容應該是完整的。
可以從以下幾方面考慮：
如果你的業務需要通過 RPC 的方式暴露給其他系統調用，這時候接口是有必要的，調用方只關注接口，不關心你的實現類，也不會因為你的實現類變更而受到影響；
測試驅動開發，在具體的實現類完成之前，需要先根據結構編寫測試用例；
現在有些框架只需要開發人員寫結構了，比如 Spring Data JPA、Feign 等等；
除了以上種種必須或最好使用接口的場景，我認為只要項目稍具規模，最好還是面向接口開發，就算一個接口對應一個實現類；當你帶領一個團隊的時候，可能這個團隊并不大，只有三五個開發人員，但是隨著項目的推進迭代，如果沒有使用面向接口開發的話，你會驚奇地發現，項目的代碼越來越復雜、越來越亂了，一個類有幾十個方法，一個方法有幾百行代碼，新來的組員看的一頭霧水，甚至你這個項目經理都不想看其中的代碼；
不要提什么制定代碼規范，規范一直都在，但是總有人不遵守，防是防不住的；
如果項目的 Service 層和 Dao 層，都是接口-實現類這樣做的，大多數時候代碼還是可以看的，相當于多了一個方法目錄，比如可以讓開發人員在寫一個新方法之前，看看能不能復用之前的方法；
當然，你不這么做的話，開發人員也可以直接在實現類中看現有的方法，只是相對來說說，在一個幾十上百行的目錄中翻找，和在一個成千上萬行的實現類的實現類中翻找（盡管有各種快捷的方法羅列出方法列表），相比還是前者更容易些。
服務端內類的調用使用接口對于一般應用場景來說，意義不大。
對于大型軟件，分層較多，模塊之間需要團隊協作，或者上下層之間調用，使用接口對于提供方和調用方可以同步開發，提供效率。
但如今的代碼架構，大多數都是客戶端APP+API的方式，所謂的API其實就相當于接口，類的接口就比較多余了。有的拿設計模式說事，認為基于接口可以不依賴實現，有利于松耦合，我寫了多年代碼，也就是第三方登錄，第三方支付等說得出的這幾個地方用的上有實用意義的接口，一般的業務代碼哪有那么多種不同的實現。
基于接口，還有一點意義就是可以用依賴注入容器創建實現類。但是在C#，不需要接口也可以直接把注入容器，Java我不熟悉不知道可不可以。
總的來說我認為有用的地方不多，不用也罷。
大家好，我是科技互聯網大叔，今天我來回答下這個問題。
大家在寫代碼的時候，其實只要有了一定的經驗，都會聽過一個詞，就是代碼風格。我看過一些書籍，比如《代碼之美》、《代碼大全》之類的，其實這些書里面都在講的一種理念就是：寫代碼跟做翻譯一樣，你要講究的是“信、達、雅”。所以寫代碼，特別是一些很多人一起構建的大型項目里，一定不能僅僅保證代碼邏輯沒有問題，而且要保證代碼風格很好，很易讀，注釋要寫清楚明白。這樣在連調和后期迭代維護的時候才不會出現大的問題。
題主說的這個問題，其實也是代碼風格的一種，從邏輯上來說的話，你完全可以不給任何類加接口，那樣的話你的代碼不會出任何問題，還是可以跑成功。但這樣寫起來，思路會比較亂，而且別人調用你的類的方法的時候，看起來比較費勁。以后如果有代碼交接的問題，也比較麻煩。
其實一般寫JAVA代碼，應該先把接口抽象出來，做好之后，再來去實現類。這就跟你寫一篇文章一樣，你寫文章之前，首先列一個大綱，然后基于大綱去寫，整個思路就不會亂。而且別人一看你的大綱就知道你這個文章表達的主要內容是什么。
1、信
開發代碼最重要的就是代碼能跑通，邏輯是對的，盡量少bug。這就是“信”，你的代碼是值得信賴的。百度的風格大家都知道：簡單可依賴。你提供的代碼一定是可以依賴的，大家可以放心的使用。
2、達
你的代碼要是通達的，邏輯清晰明白，并且注釋和接口清晰，要有良好的代碼結果和代碼風格，比如字段、方法的命名盡量“見文知意”。
3、雅
這個就是上升到藝術層面了，你的代碼要有設計，要有美感。你不是在寫代碼，而是在做一種藝術品。這個境界大叔也還沒有達到，就不瞎寫了。
不要為了模式而模式。
用接口是為了以后換業務邏輯和數據訪問方便維護和擴展。這是面向對象的編程思想-多態。
剛開始寫的時候，你會感覺會多寫了一個接口文件，沒什么用。但是當你代碼越來越多時，如果你調用的不是接口，而是具體的類。需要更改時，你只能有兩種做法，一是重構所有調用代碼里的類名，二是選擇直接修改原有的service或dao。在項目復雜的情況下這兩種做法都更容易出錯。你可以想象一下如果有1000個方法調用某個dao的class，當你需要把dao從mysql換到oracle的時候，你需要改1000個方法里的調用的類名。
如果你調用的地方是接口，那無需改方法里對象變量的類型。你只需要寫新的service或dao的impl，亦或者新的service和dao繼承舊的，只重寫部分方法。用的時候只需要通過注入就可以讓所有調用service或dao的接口使用新的實現類或方法。
這是必須的，我們的開發手冊中不允許出現Service層中方法是非實現接口的方法。
在DAO層中，如果是采用Mybatis3.0以上，本身我們編寫的方法都是基于接口的，所以不存在這個問題。
在Service層中，我們為了代碼規范、方法復用，我們必須定義接口。舉個簡單的例子：
我們一個業務系統中可能有多個業務模塊都有CRUD的方法，那我們是要在每個Service接口的方法中定義add、get、update等CRUD的方法嗎？當然不是。我們只要定義一個接口，接口中定義好這些方法，相應的業務類去實現這些接口就行，然后在各自的實現類去實現這些接口即可。
所以說，為了代碼規范和接口復用，我們需要定義接口。