我正在阅读GoF的Design Patterns，我开始怀疑。如果您使用抽象作为 C＃等语言中的接口，那么接口是多余的吗？让我们暂时搁置多重继承，因为我知道您只能通过接口实现（在C＃中）。如果使用摘要作为接口，接口是否冗余？
我想将这个逻辑应用于C＃中的DDD。几乎所有我见过的示例和实现都使用接口。我开始怀疑为什么。抽象类可以用来代替吗？在我看来，这将是一个更强大的解决方案，但是我又可能错过了一些东西，这就是我在这里问的原因。
摘要：
注： 我已经通过列出的所有类似的问题阅读，但没有人可以给我一个答案。如果我错过了，请告诉我。
对于问题1：无论支持多个继承接口都是合同规范，抽象类都是基类。
接口为类指定一组功能（认为IDisposable，IEnumerable等）提供了一种方法，建议他们服从Interface Segregation Principle。
抽象类应该实现一个可以扩展的概念，或者根据上下文可以有不同的实现（想想HttpContextBase，AbstractButton等）。
接口和抽象类之间的最大区别是概念上的。你可以争辩说，除了继承之外，一个接口和一个只有抽象方法的抽象类是一样的，但从概念上讲它们代表了不同的东西。
至于问题2：在DDD接口的背景下是实现细节。我敢说你可以做DDD，而不是使用接口或抽象类，甚至是继承。只要你有有限的环境，聚合物，实体和VOs定义良好。
总之，当你试图表达一个合约时，使用一个接口，当你想表明你的类有某种能力时，实现一个接口。当你有一个可以根据上下文提供更多实现的概念时，使用一个基类（抽象与否）。
当你这样想时，语言制造者（c＃）决定只允许单一继承，但允许实现多个接口是很有意义的。
接口的优点正是没有多重继承。通过使用接口，您可以允许类，如窗体，用户控件，组件等参与交互，否则将是diffucult /不可能。
我建议两者都做。我通常创建一个接口，并且（如果可能的话）然后创建一个继承该接口的抽象类来提供该接口的任何常见或默认实现。这给你两全其美。
你如何认为没有多重继承？ C＃只能通过接口实现多重继承。我现在做的都是界面和抽象。如果我把它全部转换成抽象的话，没有什么会真正改变。当然，我必须将声明更改为来自接口的摘要，否则没有算法会改变。界面的优点是什么？ –
虽然语法相似，但最好说明可以实现***多个接口，但是您可以继承***只有一个类。 – tcarvin
我有一个小框架，我用它有一个名为ILogicController的接口。该接口具有作为状态机的一部分的方法。如果我将它转换为名为AbstarctLogicControlBase的类，那么我的WinForms和UserControls就不能再参与该框架。表单，比如LoginForm，已经从System.Windows.Forms.Form继承。它也不能从AbstarctLogicControlBase继承。 – tcarvin
接口不是多余的。一个接口与实现无关，而抽象类是实现的。如果某些实现类更改，则使用接口的代码不必更改或重新编译。
的优点就在上面。如果你在做DDD，从具体的类开始并写一些测试。将常见的东西重构成基类（有些将是抽象的）。如果有理由让界面继续前进并这样做。重复，直到完成。
我得到你在这里说的，但它不回答任何问题。如果我改变了我的接口，那么所有的类都需要修改，就像我改变抽象类一样。在这种情况下，两人似乎也做了同样的事情。如果你将它用作接口而不是接口类型，那么抽象可以是全部或部分实现，有什么优势？ –
编辑我的答案 –
对ISP的参考真的帮助了这里。谢谢！ –