如果使用摘要作爲接口，接口是否冗餘？

我正在閱讀GoF的Design Patterns，我開始懷疑。如果您使用抽象作爲 C＃等語言中的接口，那麼接口是多餘的嗎？讓我們暫時擱置多重繼承，因爲我知道您只能通過接口實現（在C＃中）。如果使用摘要作爲接口，接口是否冗餘？

我想將這個邏輯應用於C＃中的DDD。幾乎所有我見過的示例和實現都使用接口。我開始懷疑爲什麼。抽象類可以用來代替嗎？在我看來，這將是一個更強大的解決方案，但是我又可能錯過了一些東西，這就是我在這裏問的原因。

摘要：

問題1：在OOP的與只支持單繼承，如果設計不當都有些什麼用途的接口在抽象類語言的背景？
問題2：在DDD的背景下，如果設計得當，接口的用途超過抽象類？

注：我已經通過列出的所有類似的問題閱讀，但沒有人可以給我一個答案。如果我錯過了，請告訴我。

來源

2011-10-22 Alexander Kahoun

對於問題1：無論支持多個繼承接口都是合同規範，抽象類都是基類。

接口爲類指定一組功能（認爲IDisposable，IEnumerable等）提供了一種方法，建議他們服從Interface Segregation Principle。

抽象類應該實現一個可以擴展的概念，或者根據上下文可以有不同的實現（想想HttpContextBase，AbstractButton等）。

接口和抽象類之間的最大區別是概念上的。你可以爭辯說，除了繼承之外，一個接口和一個只有抽象方法的抽象類是一樣的，但從概念上講它們代表了不同的東西。

至於問題2：在DDD接口的背景下是實現細節。我敢說你可以做DDD，而不是使用接口或抽象類，甚至是繼承。只要你有有限的環境，聚合物，實體和VOs定義良好。

總之，當你試圖表達一個合約時，使用一個接口，當你想表明你的類有某種能力時，實現一個接口。當你有一個可以根據上下文提供更多實現的概念時，使用一個基類（抽象與否）。

當你這樣想時，語言製造者（c＃）決定只允許單一繼承，但允許實現多個接口是很有意義的。

來源

2011-10-23 07:54:51

對ISP的參考真的幫助了這裏。謝謝！ –

接口的優點正是沒有多重繼承。通過使用接口，您可以允許類，如窗體，用戶控件，組件等參與交互，否則將是diffucult /不可能。

我建議兩者都做。我通常創建一個接口，並且（如果可能的話）然後創建一個繼承該接口的抽象類來提供該接口的任何常見或默認實現。這給你兩全其美。

來源

2011-10-22 15:07:24 tcarvin

你如何認爲沒有多重繼承？ C＃只能通過接口實現多重繼承。我現在做的都是界面和抽象。如果我把它全部轉換成抽象的話，沒有什麼會真正改變。當然，我必須將聲明更改爲來自接口的摘要，否則沒有算法會改變。界面的優點是什麼？ –

雖然語法相似，但最好說明可以實現***多個接口，但是您可以繼承***只有一個類。 – tcarvin

我有一個小框架，我用它有一個名爲ILogicController的接口。該接口具有作爲狀態機的一部分的方法。如果我將它轉換爲名爲AbstarctLogicControlBase的類，那麼我的WinForms和UserControls就不能再參與該框架。表單，比如LoginForm，已經從System.Windows.Forms.Form繼承。它也不能從AbstarctLogicControlBase繼承。 – tcarvin

接口不是多餘的。一個接口與實現無關，而抽象類是實現的。如果某些實現類更改，則使用接口的代碼不必更改或重新編譯。

的優點就在上面。如果你在做DDD，從具體的類開始並寫一些測試。將常見的東西重構成基類（有些將是抽象的）。如果有理由讓界面繼續前進並這樣做。重複，直到完成。

來源

2011-10-22 15:12:03

我得到你在這裏說的，但它不回答任何問題。如果我改變了我的接口，那麼所有的類都需要修改，就像我改變抽象類一樣。在這種情況下，兩人似乎也做了同樣的事情。如果你將它用作接口而不是接口類型，那麼抽象可以是全部或部分實現，有什麼優勢？ –

編輯我的答案 –

如果使用摘要作爲接口，接口是否冗餘？

回答

相關問題