Tho*_*enz 11 c# interface circular-dependency
我只是在阅读 R. Martin和M. Martin的C#中的敏捷原则,模式和实践,并在他们的书中建议将所有接口保存在一个单独的项目中,例如.接口.
举个例子,如果我有一个包含所有自定义Gui类的Gui项目,我会将它们的接口保留在Interfaces项目中.具体来说,我在Gui中有一个CustomButton类,我会在Interfaces中保留ICustomButton 接口.
优点是,任何需要ICustomButton的类都不需要引用Gui本身,而只需要更轻量级的Interfaces项目.
此外,如果Gui项目中的一个类发生更改并因此导致它被重建,则只有直接引用CustomButton的项目才需要重新编译,而引用ICustomButton的项目可能保持不变.
我理解这个概念,但看到一个问题:
可以说我有这个界面:
public interface ICustomButton
{
void Animate(AnimatorStrategy strategy);
}
正如你所看到的,它指的是AnimatorStrategy,它是一个具体的类,因此会坐在不同的项目中,我们称之为动画.现在接口项目需要引用动画.另一方面,如果Animation使用Interfaces中定义的接口,则需要引用它.
循环依赖 - "我们来了".
我看到,这个问题的唯一解决方案是,接口中定义的所有方法都接受本身作为接口的输入.试图实现这一点,很可能会产生多米诺骨牌效应,并且很快就需要为最基本的类实现接口.
我不知道我是否愿意在开发中处理这种开销.
有什么建议？
LBu*_*kin 16
始终,永远,永远谨慎 - 特别是近乎所有,没有,或每一个.
您是否应该始终将所有接口放在单独的程序集中？不 - 不一定.
您是否应该实现您希望代码的外部使用者实现的接口 - 可能.如果您希望项目中的多个程序集依赖它们,我会将接口放入外部程序集中 - 这有助于破坏耦合依赖性.我也使用这种做法来解决循环引用问题,其中程序集需要知道彼此之间的接口.
我不会将仅在项目内部使用的接口放在单独的程序集中.当我的项目相对较小时,我也不会将接口提升到自己的程序集中 - 或者如果没有依赖于它们的程序集,则不打算使用接口.
至于您提供的示例 - 我建议您考虑不从接口引用系统中的类.只要有可能,我尝试让接口只引用其他接口 - 这使事情相对分离.你无法总是实现这一点 - 所以当你拥有这些类型的接口时 - 你必须将它们与它们所依赖的组件保持在一起.
如果您决定将接口放入单独的程序集中 - 则不必将它们全部放入单个程序集中.您可能希望根据其预期用途将其分解 - 这样,消费者可以仅仅引入与特定功能域相关的接口.