問題一：為乙個子系統定義介面，然後其它子系統通過介面來進行訪問該子系統。這時其它子系統就要「呼叫」「該系統的介面」，怎麼個呼叫法，通過實現介面中的方法？？？
問題二：比如「後台維護子系統」，它其中有很多「用例類」（類是根據用例抽象來的），每個類都有「增、刪、改、查」，這些「增、刪、改、查」可不可以抽象出來，抽象成介面，或者基類。
問題三：如果抽象出介面，介面應該怎樣定義？？？
這個介面是對「子系統外」開放，還是對「子系統內「開放？
第一種方式：介面中定義「增、刪、改、查」這些方法，那麼方法的實現就是「子系統中的用例類」，子系統外的「子系統」有辦 法訪問嗎？？？這是介面起到什麼樣的作用？？？這是介面換成基類或是抽象類可能更合適。
第二種方式：介面中定義獲取「該子系統用例類」的方法，這時「子系統外」的子系統就可以實現這些「獲取」「該 子系統用例類」的方法，進而得到「系統用例類」，進行操作。這樣「子系統」就可以被外部使用，這樣的介面怎樣定義？
問題四：如果抽象出基類或是抽象類
「把公共的**抽取出來，減少**的重複性」這樣的抽象類才算合格，有沒有實現「增、刪、改、查」通用的方法？？？
答： 1. 介面這個詞不一定僅僅是空洞的字眼，可能有各種具體的解釋，而不一定是特指c#的inte***ce。特別是在設計時期，介面就是指子系統之間的通訊，並沒有糾纏於具體的程式設計語句。比如說傳統的api，這裡的i就是介面的意思。再比如說通訊協議，也是定義了跨程序的系統的一些介面。當然直接使用程式語言的inte***ce語法定義的型別也是介面。所以說「呼叫介面」這就要具體問題具體分析，你不去了解人家說的是什麼介面，你就不知道到底什麼才是「呼叫介面」。千萬不要死摳字眼，而要先去看看字眼在別人心目中（而不是自己心目中）是什麼意思。
2. 所謂「增刪改查」對於乙個真正流行、實用的業務介面設計來說，不超過30%的內容。實際上只有那些沒畢業的學生，或者那些一輩子沒有脫離了學生習慣的「架構師」，才會從這個角度出發。當然一切資訊的改變你都可以說是「怎上改查」，但是這就好像去問「回字有幾種寫法」而不是去問「回家是什麼感覺」一樣，糾纏於底層的片段資料的增刪改查，而沒有直截了當地為前端需求提供介面。比如說我們要邀請所有「快女」出席晚宴，除了說這是給「邀請」動作執行「資料庫新增」以外，你還能不能說點真正的設計知識呢？前端只需要訪問「邀請」這個介面功能，它才不需要去管後台有沒有什麼資料庫。
回到你的問題，介面建模應該是設計中得到的乙個結果，然後用來做演示（即憑此實現一些mock的暫時實現）跟客戶溝通，在原型基礎上重新理解使用者需求，重新擴充甚至廢棄介面設計。從需求出發，了解前端是一單個事務的需求還是一連串需求的方式跟後台通訊，了解通訊時序而設計出介面，而不是從什麼底層資料庫的增刪改查來設計介面。
至於說對於資料庫系統的增刪改查，資料庫系統早已經有介面了，大多用不著你再去以很低階的方式包裝什麼dal。除非你需要對資料庫系統操作進行很高階的包裝。
3. 你的問題有點混沌。我想你一味地從程式設計出的發，缺乏從測試出發的視角。不論是產品設計，還是開發規劃，還是質量管理，等等都是落實在測試上。產品設計者不需要面面俱到，但是它的設計文件要恰好可以落實到測試上即可。開發時，假設乙個子系統介面的實現需要3天時間，然後我們留出2天時間富餘量，那麼應該怎樣分配時間？可能需要用半天時間定義好介面以及測試程式，然後用4天時間執行開發工作，並且用4天半時間執行測試工作，即開發過程中隨時要用介面來測試和指導開發工作，開發的目的只是為了讓測試可以通過，做更多的工作是多餘的、有害的。介面起到了讓測試可以在開發之前啟動的作用。
至於你說的什麼「抽象類、基類」什麼的，我不回答你。此時不用糾結這些，甚至我們沒有必要對介面必須是什麼具體形式作出規定。首先應該強調的是工程化開發方法的流程，如果抓住實現這個關鍵環節，那麼就反而可以「放開」那些細枝末節的什麼介面形式隨便去發揮。
4. 實際上你應該更多從測試角度去考慮。假設你希望，比如說「住院部病人」物件可以放入「病人的報銷流程」的所有測試中，同時把「門診病人」也可以帶入所有的病人報銷流程的測試中，不應該丟擲任何異常，這時候你就自然會考慮抽象問題。如果你為了抽象而抽象、為了復用而復用，比如說僅僅因為出差人員也有報銷動作於是把出差人員都當作病人來建模，那麼可能張冠李戴而產生嚴重的測試bug。
關於介面的例項
關於介面 inte ce singer class student implements singer void study public class animal public static void main string args student ss1 new student singer ...
關於介面的認識
1 什麼是介面?1.1介面的格式 修飾符 inte ce 介面名 1.2使用介面需要注意的 1.所有的方法都是抽象方法。2.介面內的成員預設都是static final以及public。3.介面沒有構造方法。4.介面可以被介面繼承，不能被類 抽象類 繼承。介面可以繼承兩個介面 5.介面需要被實現，子...
關於介面的理解
這兩天在進行spring的學習，理解起ioc來有些困難，於是發覺自己對依賴理解的太少，昨晚到今天通過網路找資料好好的看了下介面及其繼承。inte ce是高度抽象的，必須得以實現，其設計與應用與實際問題和內部程式結構緊密關聯。是實現可復用的主要手段，可能會產生很多的類，從依賴優化的角度，來挖掘隱藏類，...