当前位置：文江博客话题详情

为每个类提取一个接口是最佳实践吗？

发布于 2024-09-05 18:07:58 字数 134 浏览 11 评论 0原文

我见过代码中每个类都有一个它实现的接口。

有时，它们没有通用的接口。

它们就在那里，并且被用来代替具体的物体。

它们不为两个类提供通用接口，并且特定于该类解决的问题的领域。

有理由这样做吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不必你懂 2024-09-12 18:07:59

为什么需要接口？切实而深入地思考。接口并不真正附加到类，而是附加到服务。接口的目标是允许其他人使用您的代码而不向他们提供代码。所以它涉及到服务及其管理。

再见

回复收藏 0 原文

丶情人眼里出诗心の 2024-09-12 18:07:58

不会。

接口对于具有复杂行为的类很有用，如果您希望能够创建该接口的模拟或假实现类以在单元测试中使用，那么接口尤其方便。

但是，某些类没有很多行为，可以更像值一样对待，并且通常由一组数据字段组成。为这样的类创建接口没有什么意义，因为当模拟或提供接口的替代实现没有意义时，这样做会带来不必要的开销。例如，考虑一个类：

class Coordinate
{
  public Coordinate( int x, int y);
  public int X { get; }
  public int y { get; }
}

您不太可能希望接口 IColined 与此类配合使用，因为除了简单地获取和设置 X< 之外，以任何其他方式实现它没有什么意义。 /code> 和 Y 值。

但是，

class RoutePlanner
{
   // Return a new list of coordinates ordered to be the shortest route that
   // can be taken through all of the passed in coordinates.
   public List<Coordinate> GetShortestRoute( List<Coordinate> waypoints );
}

您可能需要一个用于 RoutePlanner 的 IRoutePlanner 接口，因为有许多不同的算法可用于规划路线。

另外，如果您有第三个类：

class RobotTank
{
   public RobotTank( IRoutePlanner );
   public void DriveRoute( List<Coordinate> points );
}

通过为 RoutePlanner 提供一个接口，您可以为 RobotTank 编写一个测试方法，该方法使用模拟 RoutePlanner 创建一个测试方法> 只返回一个没有特定顺序的坐标列表。这将允许测试方法检查坦克是否在坐标之间正确导航，而无需测试路线规划器。这意味着您可以编写一个仅测试一个单元（坦克）的测试，而无需测试路线规划器。

不过，您会发现，将真实坐标输入到这样的测试中非常容易，而无需将它们隐藏在 IColined 界面后面。

No.

Interfaces are good for classes with complex behaviour, and are especially handy if you want to be able to create a mock or fake implementation class of that interface for use in unit tests.

But, some classes don't have a lot of behaviour and can be treated more like values and usually consist of a set of data fields. There's little point in creating interfaces for classes like this because doing so would introduce unnecessary overhead when there's little point in mocking or providing alternative implementations of the interface. For example, consider a class:

class Coordinate
{
  public Coordinate( int x, int y);
  public int X { get; }
  public int y { get; }
}

You're unlikely to want an interface ICoordinate to go with this class, because there's little point in implementing it in any other way than simply getting and setting X and Y values.

However, the class

class RoutePlanner
{
   // Return a new list of coordinates ordered to be the shortest route that
   // can be taken through all of the passed in coordinates.
   public List<Coordinate> GetShortestRoute( List<Coordinate> waypoints );
}

you probably would want an IRoutePlanner interface for RoutePlanner because there are many different algorithms that could be used for planning a route.

Also, if you had a third class:

class RobotTank
{
   public RobotTank( IRoutePlanner );
   public void DriveRoute( List<Coordinate> points );
}

By giving RoutePlanner an interface, you could write a test method for RobotTank that creates one with a mock RoutePlanner that just returns a list of coordinates in no particular order. This would allow the test method to check that the tank navigates correctly between the coordinates without also testing the route planner. This means you can write a test that just tests one unit (the tank), without also testing the route planner.

You'll see though, it's quite easy to feed real Coordinates in to a test like this without needing to hide them behind an ICoordinate interface.

回复收藏 0 原文

仙女 2024-09-12 18:07:58

_{重新审视这个答案后，我决定稍微修改一下。}

不，为每个类提取接口并不是最佳实践。这实际上可能适得其反。然而，接口很有用，有几个原因：

测试支持（模拟、存根）。
实现抽象（进一步到 IoC/DI）。
C# 中的协方差和逆变支持等辅助功能。

为了实现这些目标，接口被认为是良好的实践（并且实际上是最后一点所必需的）。根据项目规模，您会发现您可能永远不需要与接口对话，或者由于上述原因之一而不断提取接口。

我们维护一个大型应用程序，其中有些部分很棒，但有些部分却缺乏关注。我们经常发现自己重构以从类型中提取接口以使其可测试，或者因此我们可以更改实现，同时减少更改的影响。如果您对公共 API 不严格，我们这样做还可以减少具体类型可能意外施加的“耦合”效应（接口只能代表公共 API，因此对我们来说本质上变得相当严格）。

也就是说，可以在没有接口的情况下抽象行为，并且可以在不需要接口的情况下测试类型，因此它们不是上述的要求。只是您可能用来支持您完成这些任务的大多数框架/库都将针对接口有效运行。

_{I'll leave my old answer for context.}

接口定义公共契约。实现接口的人必须实现这个契约。消费者只能看到公共合同。这意味着实施细节已从消费者手中抽象。

如今，对此的直接使用是单元测试。接口很容易被模拟、存根、伪造，凡是你能想到的。

另一个直接使用是依赖注入。给定接口的注册具体类型被提供给使用该接口的类型。该类型并不具体关心实现，因此它可以抽象地请求接口。这允许您在不影响大量代码的情况下更改实现（只要合约保持不变，影响范围就非常小）。

对于非常小的项目，我倾向于不打扰，对于中型项目，我倾向于在重要的核心项目上打扰，而对于大型项目，几乎每个类都有一个接口。这几乎总是为了支持测试，但在某些情况下是注入行为或抽象行为以减少代码重复。

_{After revisiting this answer, I've decided to amend it slightly.}

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:

Test support (mocks, stubs).
Implementation abstraction (furthering onto IoC/DI).
Ancillary things like co- and contra-variance support in 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.

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.

回复收藏 0 原文

分分钟 2024-09-12 18:07:58

让我引用 OO 大师 Martin Fowler 的话，为这个帖子中最常见的答案添加一些坚实的理由。

这段摘录来自“企业应用程序架构模式”（列入“编程经典”和/或“每个开发人员必读”书籍类别）。

[模式]分离的界面
(...)
何时使用
当您需要打破系统两个部分之间的依赖关系时，可以使用分离接口。
(...)
我遇到过许多开发人员，他们为他们编写的每个类都有单独的接口。我认为这太过分了，尤其是对于
应用程序开发。保持单独的接口和
实现是额外的工作，特别是因为你经常需要工厂
类（带有接口和实现）也是如此。为了
我建议您仅在需要时才使用单独的界面
打破依赖性或者你想要有多个独立的
实现。如果你把接口和实现
放在一起，稍后需要将它们分开，这是一个简单的重构
这可以推迟到您需要时再做。

回答你的问题：不，

我自己见过一些这种类型的“花哨”代码，开发人员认为他很可靠，但实际上难以理解，难以扩展并且过于复杂。

回复收藏 0 原文

静待花开 2024-09-12 18:07:58

为项目中的每个类提取接口没有任何实际原因。那就太过分了。他们必须提取接口的原因是他们似乎实现了 OOAD 原则“编程到接口，而不是实现”。您可以通过示例此处找到有关此原则的更多信息。

回复收藏 0 原文

源来凯始玺欢你 2024-09-12 18:07:58

拥有接口和接口编码使得更换实现变得更加容易。这也适用于单元测试。如果您正在测试一些使用该接口的代码，您可以（理论上）使用模拟对象而不是具体对象。这使您的测试更加集中且粒度更细。

从我所看到的情况来看，在实际的生产代码中切换测试（模拟）的实现更为常见。是的，它对单元测试很感兴趣。

回复收藏 0 原文

携余温的黄昏 2024-09-12 18:07:58

我喜欢可以在时间或空间上以两种不同方式实现的事物的接口，即将来可以以不同的方式实现，或者在代码的不同部分有 2 个不同的代码客户端这可能需要不同的实现。

代码的原始编写者可能只是机器人编码，或者他们很聪明，正在为版本弹性做准备，或者为单元测试做准备。更可能是前者，因为版本弹性是一种不常见的需求——（即部署客户端且无法更改的位置，并且将部署必须与现有客户端兼容的组件）

我喜欢依赖项值得隔离的事物的接口来自我计划测试的其他一些代码。如果这些接口也不是为了支持单元测试而创建的，那么我不确定它们是个好主意。接口的维护成本很高，当需要使一个对象可与另一个对象交换时，您可能希望接口仅应用于少数方法（以便更多的类可以实现该接口），最好使用抽象类（以便可以在继承树中实现默认行为）。

所以预先需要接口可能不是一个好主意。

回复收藏 0 原文