我已經在大學的一些課程中使用Java編程，但是我有以下問題：從方法上來說，每個類都應該實現一個接口嗎？不這樣做是不明智的做法？您能描述一下使用接口不是一個好主意的情況嗎？編輯：就個人而言，我喜歡將所有對象都使用接口的概念作為一種方法和習慣，即使這顯然沒有好處。Eclipse使用所有方法自動創建了一個類文件，因此無論如何都不會浪費時間。
3 回答
躍然一笑
TA貢獻1826條經驗 獲得超6個贊
如果您不打算使用它，則無需創建接口。
通常，在以下情況下需要接口：
您的程序將為您的組件提供幾種實現。例如，默認實現是代碼的一部分，而模擬實現是在JUnit測試中使用的。一些工具會自動創建模擬實現，例如EasyMock。
您想通過諸如Spring或JBoss Micro-Container之類的框架對此類使用依賴注入。在這種情況下，最好使用一個接口指定一個類與其他類的依賴關系。
largeQ
TA貢獻2039條經驗 獲得超8個贊
每個類都提供一個非私有API，但確實實現了一個接口（即合同）。是否選擇將接口表示為Java接口取決于實現是否為“變化的概念”。
如果您完全確定只有一種合理的實現，則不需要接口。否則，界面將允許您更改實現而無需更改客戶端代碼。
假設您以后對新的要求有完全的控制權，那么有些人會大喊“ YAGNI”。其他人會公平地擔心，他們將需要更改不變的-已發布的API。
如果您不實現接口（并使用某種工廠進行對象創建），則某些類型的更改將迫使您違反開放式封閉原則。在某些情況下，這在商業上是可以接受的，在其他情況下則不是。
您能描述一下使用接口不是一個好主意的情況嗎？
在某些語言中（例如C ++，C＃，但不包括Java），如果您的類不包含虛擬方法，則可以提高性能。
在小型程序中，或者在沒有發布API的應用程序中，維護單獨的接口的成本可能很小。
如果由于將接口和實現分開而導致復雜性顯著增加，則可能未將接口用作合同。接口降低了復雜性。從消費者的角度來看，組件成為滿足合同條款的商品，而不是本身具有復雜實施細節的實體。
添加回答
舉報
0/150
提交
取消