對於樓主這個問題,我之前也很糾結,感覺很煩躁.不過後來的開發中,我感覺到了介面的作用很棒.
我對介面的理解就是拓展,便於拓展.
這麼來說吧.有乙個財務系統,裡面有計算員工工資的功能.
當然,不同的崗位,不同的職位工資計算肯定不一樣.
比如說,實習員工肯定就只有乙個基本工資,正式員工肯定包含了基本工資+業績+獎金等等了.
後面還有經理什麼的等等了.
面對這種情況,財務系統可以提供乙個介面
inte***ce 結算
然後後面有 實習生類,正式員工類,經理類等等去實現它.
在結算的時候,呼叫不同的實現類來實現計算.是不是很方便,很清晰.
當然這普通的結算可能還無法體現出介面的強大.
再舉例,玩遊戲,要顯示影象,這個顯示影象的效果肯定是交給顯示卡了.
系統本身是不管的,所以系統提供了乙個介面
inte***ce 顯示影象
然後各大顯示卡生產廠家去實現這個介面.
然後你拆入不同的顯示卡,得到的效果就不一樣了.
好理解吧.
但是可能還是不足以解決你的疑問,我可以直接用類實現,丟給系統呼叫不就完了麼.
但是,你面對小型的系統,好辦,但是大型系統呢,你需要去了解整個系統的結構,他應該在**呼叫你的方法.
每做乙個功能都要去了解整個系統介面,真的很煩躁.你開發乙個功能,難道還要去理解整個系統,多影響效率啊.
試想如果有乙個介面給我,告訴我實現哪些方法就夠了,這樣的開發是不是很爽呢?
就好比說架構師把系統的架構設計好,放出介面,乙個介面是乙個功能模組
然後丟團隊的程式設計師,團隊的程式設計師根本不用去考慮這個系統是如何設計的,要怎麼做才不會亂,不會影響到其他同事的開發.每個人只用管自己要實現的介面,只用去管自己的事就好了.
最後組合在一起.
突然有一天,我需要修改某乙個功能,也只用重寫乙個介面的實現就完了.而不必整個系統的大動干戈.
或者在執行的時候,出錯了,也能很快的定位,是哪個部件有問題.而不必說整個系統的去除錯,一句一句**的看.多煩啊.
我覺得程式設計要做到嚴謹,各司其職,邏輯結構清晰,可拓展,可維護,使用介面是乙個不錯的選擇.
這是我對介面的理解,不知道有沒有幫到你.也不知道對不對.僅供你參考.
乙個人開發，b模組呼叫a模組。先寫a，再寫b即可。沒必要使用介面。
2個人開發，各自寫各自的，沒有呼叫關係，沒必要寫介面。
2個人開發，b呼叫a，但b和a同時開發，可以讓a先把方法寫好定義，b呼叫就好了，不必使用介面。
4個人開發，b可以呼叫a1,也可以呼叫a2，但究竟呼叫哪個，由c模組的邏輯決定。於是，c寫了乙個ia 介面。a1和a2各自按自己的邏輯實現這個介面。b寫自己的邏輯，需要用的時候，告訴c我要用a介面了。c來寫邏輯在什麼時候下給b返回a1介面，什麼時候返回a2介面。
強烈建議 restful api 介面返回如下格式
只有返回這樣的格式，拿到 資料解析時才能快速解析介面返回的資料 強烈 建議的返回格式class apiresponseresult 介面是否有錯誤 public string error 錯誤訊息 public t rawdata 泛型的，本來想返回的資料 返回這種格式，取資料相當方便public ...
遍歷List集合的方式，總結如下
list allusers list map.get allusers for user user allusers 方法一 普通迴圈語句，具體使用get i 取出 for int i 0 i allusers.size i 方法一 迭代器進行遍歷，while迴圈控制輸出 iterator it a...
關於抽象類與介面的總結
在物件導向的概念中，我們知道所有的物件都是通過類來描繪的，但是並不是所有的類都是用來描繪物件的，如果乙個類中沒有包含足夠的資訊來描繪乙個具體的物件，這樣的類就是抽象類。抽象類往往用來表徵我們在對問題領域進行分析 設計中得出的抽象概念，是對一系列看上去不同，但是本質上相同的具體概念的抽象，我們不能把它...