oop - 什么时候需要以接口(interface)的形式创建抽象？

Question

您何时鼓励针对接口(interface)而不是直接针对具体类进行编程？

我遵循的指导方针是在代码需要跨越逻辑/物理边界时创建抽象，尤其是在涉及与基础设施相关的问题时。

另一个检查点是，由于可能存在额外的关注代码(例如缓存、事务感知、调用 Web 服务而不是进程内执行)，或者此类依赖项是否直接引用了基础设施集成点，将来依赖项是否可能会发生变化。

如果代码依赖于不需要控制来跨越逻辑/物理边界的东西，我或多或少不会创建抽象来与它们交互。

我错过了什么吗？

Answer 1

此外，使用接口(interface)时

需要以特定方式对多个对象进行操作，但本质上并不相关。也许您的许多业务对象都访问特定的实用程序对象，当他们这样做时，他们需要为自己提供对该实用程序对象的引用，以便实用程序对象可以调用特定的方法。在接口(interface)中拥有该方法并将该接口(interface)传递给该实用程序对象。

将接口(interface)作为参数传递在单元测试中非常有帮助。即使您只有一种类型的对象具有特定的接口(interface)，因此实际上并不需要定义的接口(interface)，您也可以在单元测试中为“fake”该对象定义/实现一个接口(interface)。

与前 2 个项目符号相关，请查看 Observer pattern和 Dependency Injection .我并不是说要实现这些模式，但它们说明了接口(interface)真正有用的地方的类型。

另一个转折是实现几个 SOLID Principal，Open Closed principal和 Interface Segregation principle .就像前面的子弹一样，不要因为在任何地方(至少立即)严格执行这些原则而感到压力，但是使用这些概念来帮助您将思维从仅仅考虑对象的位置转移到更多地考虑契约(Contract)和依赖关系

最后，我们不要把它弄得太复杂:我们处于 .NET 的强类型世界中。如果您需要调用方法或设置属性，但您传递/使用的对象可能根本不同，请使用接口(interface)。

我要补充一点，如果您的代码不会被另一个库引用(至少有一段时间)，那么在特定情况下是否使用接口(interface)的决定是您可以负责任地推迟的决定。如今，“提取接口(interface)”重构很容易做到。在我当前的项目中，我有一个正在传递的对象，我在想也许我应该切换到一个界面；我不是在强调它。