c# - 组织界面

Question

我正在阅读 R. Martin 和 M. Martin 所著的 C# 中的敏捷原则、模式和实践，他们在他们的书中建议，将所有接口(interface)保存在一个单独的项目中，例如。 接口(interface)。

例如，如果我有一个 Gui 项目，其中包含我所有的自定义 Gui 类，我会将它们的接口(interface)保留在 Interfaces 项目中。具体来说，我在 Gui 中有一个 CustomButton 类，我会在 Interfaces 中保留 ICustomButton 接口(interface)。

优点是，任何需要 ICustomButton 的类都不需要引用 Gui 本身，而只需要引用重量轻得多的 Interfaces 项目。

此外，如果 Gui 项目中的类发生更改并因此导致重建，则只有直接引用 CustomButton 的项目需要重新编译，而引用 ICustomButton 的项目可能保持不变.

我理解这个概念，但看到一个问题:

假设我有这个界面:

public interface ICustomButton
{
    void Animate(AnimatorStrategy strategy);
}

如您所见，它引用了 AnimatorStrategy，这是一个具体的类，因此将位于不同的项目中，我们称它为 Animation。现在界面工程需要引用Animation。另一方面，如果 Animation 使用 Interfaces 中定义的接口(interface)，则需要引用它。

循环依赖 - “我们来了”。

据我所知，这个问题的唯一解决方案是，接口(interface)中定义的所有方法都采用本身就是接口(interface)的输入。尝试实现这一点很可能会产生多米诺骨牌效应，并且即使是最基本的类也很快需要实现一个接口(interface)。

我不知道我是否愿意在开发中处理这种开销。

有什么建议吗？

Answer 1

谨防总是、永远和从不 - 尤其是几乎所有、没有或每一个。

您是否应该总是将所有接口(interface)放在一个单独的程序集中？不 - 不一定。

您是否应该放置您希望代码的外部使用者实现的接口(interface) - 可能。如果您希望项目中的多个程序集依赖它们，我会将接口(interface)放入外部程序集 - 这有助于打破耦合依赖性。我还使用这种做法来解决循环引用问题，其中程序集需要了解彼此之间的接口(interface)。

我不会将仅在项目内部使用的接口(interface)放在单独的程序集中。当我的项目相对较小时，我也不会将接口(interface)提升到它们自己的程序集中 - 或者接口(interface)不打算在没有依赖它们的程序集的情况下使用。

至于您提供的示例 - 我建议您考虑不要从接口(interface)引用系统中的类。只要有可能，我都会尝试让接口(interface)只引用其他接口(interface)——这样可以使事情相对解耦。您无法始终实现这一点 - 因此当您拥有这些类型的接口(interface)时 - 您必须将它们与它们所依赖的程序集保持在一起。

如果您决定将接口(interface)放入一个单独的程序集中 - 您不必将它们全部放入一个程序集中。您可能希望按预期用途将它们分解 - 这样消费者就可以只引入与特定功能领域相关的界面。