抽象类或接口。哪种方式是正确的？
有两种方法可以选择抽象类或接口。 Microsoft 解决方案和 Oracle 解决方案：
Microsoft，设计指南：
使用抽象（在 Visual Basic 中为 MustInherit）类而不是接口来将契约与实现解耦。
http://msdn.microsoft.com/en-us/library/ms229013.aspx
Oracle，Java 教程：
如果抽象类仅包含抽象方法声明，应将其声明为接口。
http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html
我的问题是哪种方式是正确的？微软还是甲骨文的解决方案？请注意，我认为抽象类或接口之间的选择不应该取决于编程语言（Java 或 C#）。
There are two way for choosing between abstract class or interface. Microsoft solution and Oracle solution:
Microsoft, design guideline:
Do use abstract (MustInherit in Visual Basic) classes instead of interfaces to decouple the contract from implementations.
http://msdn.microsoft.com/en-us/library/ms229013.aspx
Oracle, The Java Tutorials:
If an abstract class contains only abstract method declarations, it should be declared as an interface instead.
http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html
My question is which way is correct? Microsoft or Oracle solution? Note that I think choose between abstract class or interface should not depends on programming language (Java or C#).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我没记错的话，微软关于使用抽象类的建议源于使用抽象类重用实现的能力，这是接口无法做到的。
另请注意，您链接到的 Microsoft 页面专门指导编写代码库以在多个项目之间共享/重用。在这种情况下，您可能会自己编写接口的所有实现，可能是在同一个程序集中。处理单一产品或系统的良好实践会有所不同。
我在多种语言的多种代码库中看到的一种常见方法是：
世界中常见的第四步是提供基于接口构建的便利扩展函数。
If I recall my blog reading correctly, the Microsoft advice to use abstract classes stems from the ability to reuse implementation with an abstract class, something you can't do with an interface.
Note also that the Microsoft page you linked to is specifically guidance for writing code libraries for sharing/reuse across multiple projects. The likelihood in this situation is that you'll be writing all the implementations of the interface yourself, probably within the same assembly. Good practices for working on a single product or system will vary somewhat.
One common approach that I've seen across a number of codebases in a number of languages is this:
A fourth step common in the .NET world is to provide convenience extension functions built on the interface.
它们是针对不同上下文的两个声明。
您引用的微软指南是“设计类库”。它说明了在那里青睐抽象类的原因：您可以在不破坏任何内容的情况下添加功能。
对于跨层和其他边界的分离和解耦，微软还建议使用接口。
They are 2 statements for different contexts.
The Microsoft guideline you quote from is for "Designing Class Libraries". And it states the reason for favoring abstract classes there: you can add functionality without breaking anything.
For separation and decoupling over layers and other boundaries, Microsoft also advices interfaces.
接口不包含任何实现——它是一个契约。它允许完全解耦。
如果我想提供一些通用的实现，同时强制继承类具体类提供一些特定于该类的实现，我将从接口转到抽象（基）类。这提供了更少的解耦。
另请注意，许多语言（如 C#）（以及 .net 语言（如 VB.net 等））以及 Java 不允许多重继承，因此接口成为允许类具有多种行为的一种方式。
An interface carries no implementation - it's a contract. It allows for complete decoupling.
I will go from an interface to an abstract (base) class if I want to provide some common implementation while forcing on the inheriting class concrete class to provide some implementation specific to that class. That's provides a little less decoupling.
Also be aware that many languages like C# (and .net languages like VB.net etc...) as well as Java do not allow multiple inheritance so interfaces become a way of allowing a class to have many behaviors.