为每个类提取一个接口是最佳实践吗? [英] Is it the best practice to extract an interface for every class?
问题描述
我见过这样的代码，其中每个类都有一个它实现的接口.
I have seen code where every class has an interface that it implements.
有时它们没有通用的接口.
Sometimes there is no common interface for them all.
它们就在那里，被用来代替具体的对象.
They are just there and they are used instead of concrete objects.
它们不为两个类提供通用接口，并且特定于该类解决的问题的领域.
They do not offer a generic interface for two classes and are specific to the domain of the problem that the class solves.
有什么理由这样做吗?
推荐答案
重温这个答案后，我决定稍微修改一下.
不，为每个类提取接口不是最佳做法.这实际上可能适得其反.但是，接口之所以有用有以下几个原因:
No, it's not best practice to extract interfaces for every class. This can actually be counterproductive. However, interfaces are useful for a few reasons:
- 测试支持(模拟、存根).
- 实现抽象(进一步发展到 IoC/DI).
- C# 中的协变和逆变支持等辅助功能.
为了实现这些目标，接口被认为良好实践(实际上是最后一点所必需的).根据项目的大小，您会发现您可能永远不需要与接口交谈，或者由于上述原因之一而不断地提取接口.
For achieving these goals, interfaces are considered good practice (and are actually required for the last point). Depending on the project size, you will find that you may never need talk to an interface or that you are constantly extracting interfaces for one of the above reasons.
我们维护了一个大型应用程序，其中有些部分很棒，有些则缺乏关注.我们经常发现自己在重构以从类型中提取接口以使其可测试，或者这样我们就可以更改实现，同时减少该更改的影响.我们这样做也是为了减少如果您对公共 API 不严格(接口只能代表公共 API，因此对我们来说本质上变得非常严格)，具体类型可能会意外强加的耦合"效应.
We maintain a large application, some parts of it are great and some are suffering from lack of attention. We frequently find ourselves refactoring to pull an interface out of a type to make it testable or so we can change implementations whilst lessening the impact of that change. We also do this to reduce the "coupling" effect that concrete types can accidentally impose if you are not strict on your public API (interfaces can only represent a public API so for us inherently become quite strict).
也就是说，可以在没有接口的情况下抽象行为，也可以在不需要接口的情况下测试类型，因此它们不是上述的要求.只是您可能用于在这些任务中为您提供支持的大多数框架/库将针对接口有效运行.
我会把我的旧答案留给上下文.
That said, it is possible to abstract behaviour without interfaces and possible to test types without needing interfaces, so they are not a requirement to the above. It is just that most frameworks / libraries that you may use to support you in those tasks will operate effectively against interfaces.
I'll leave my old answer for context.
接口定义了一个公共契约.实现接口的人必须实现这个契约.消费者只能看到公共合同.这意味着实施细节已经从消费者那里抽象出来.
Interfaces define a public contract. People implementing interfaces have to implement this contract. Consumers only see the public contract. This means the implementation details have been abstracted away from the consumer.
最近立即使用的是单元测试.接口很容易模拟、存根、伪造，你可以说出来.
An immediate use for this these days is Unit Testing. Interfaces are easy to mock, stub, fake, you name it.
另一个直接使用的是依赖注入.给定接口的注册具体类型提供给使用接口的类型.类型并不特别关心实现，所以它可以抽象地请求接口.这使您可以在不影响大量代码的情况下更改实现(只要合约保持不变，影响区域就非常小).
Another immediate use is Dependency Injection. A registered concrete type for a given interface is provided to a type consuming an interface. The type doesn't care specifically about the implementation, so it can abstractly ask for the interface. This allows you to change implementations without impacting lots of code (the impact area is very small so long as the contract stays the same).
对于非常小的项目，我倾向于不打扰，对于中型项目，我倾向于在重要的核心项目上打扰，对于大型项目，几乎每个类都有一个界面.这几乎总是支持测试，但在某些情况下是注入行为，或行为抽象以减少代码重复.
For very small projects I tend not to bother, for medium projects I tend to bother on important core items, and for large projects there tends to be an interface for almost every class. This is almost always to support testing, but in some cases of injected behaviour, or abstraction of behaviour to reduce code duplication.
这篇关于为每个类提取一个接口是最佳实践吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
