我们在一个中型项目(超过6个月的3个开发人员)上工作,需要做出以下决定:我们希望将接口与具体实现分开.第一种是将接口存储在单独的文件中.
我们想进一步分离数据:我们希望在一个.CS文件中添加一个带有接口的项目(CSPROJ)以及带有帮助类的另一个.CS文件(比如此接口中使用的一些公共类,一些枚举等).然后,我们想要另一个项目(CSPROJ),它具有工厂模式,具体的接口实现和其他"工作者"类.
任何想要创建实现此接口的对象的类都必须包含第一个包含接口和公共类的项目,而不是实现本身.
这个解决方案有一个很大的缺点:它将程序集的数量乘以2,因为每个"普通"项目都有一个带有interace的项目和一个带有实现的项目.
你会推荐什么？您认为将所有接口放在一个单独的项目中而不是在其自己的项目中的一个接口上是一个好主意吗？
Wim*_*nen 65
我会区分这样的接口:
独立接口,您可以在不讨论项目其余部分的情况下描述其目的.将它们放在一个专用的"接口组件"中,它可能被项目中的所有其他组件引用.典型的例子:ILogger,IFileSystem,IServiceLocator.
类耦合接口实际上只在项目类的上下文中有意义.将它们放在与它们所连接的类相同的程序集中.
例如:假设您的域模型有一个Banana类.如果您通过IBananaRepository界面检索香蕉,那么该界面与香蕉紧密相连.在不了解香蕉的情况下实现或使用界面是不可能的.因此,接口与同一组件驻留在逻辑上是合乎逻辑的Banana.
前面的示例具有技术耦合,但耦合可能只是一个逻辑耦合.例如,即使接口声明没有技术链接,IFecesThrowingTarget接口也只能作为Monkey类的协作者Monkey.
我的答案取决于可以与类进行一些耦合的概念.隐藏界面背后的一切都是错误的.有时可以"新建"一个类,而不是注入它或通过工厂创建它.
Max*_*erl 12
是的,我认为这是一个好主意.实际上,我们一直在这里做,最后我们必须这样做,原因很简单:
我们使用Remoting来访问服务器功能.因此,服务器上的远程对象需要实现接口,客户端代码必须能够访问接口才能使用远程对象.
一般来说,当你将接口放在一个单独的项目中时,我认为你更松散耦合,所以就这样去做吧.拥有2个组件并不是一个真正的问题,是吗？
加成:
我突然想到:通过将接口放在一个单独的程序集中,您还可以获得能够重用接口的好处,如果它们中的一些足够通用的话.
除非它为您的应用程序架构提供可靠的好处,否则我不会这样做.
最好关注你正在创建的组件数量.即使一个接口及其实现在同一个程序集中,你仍然可以通过一点点训练来实现正确寻求的解耦.
我认为你首先应该考虑所有接口是否属于项目的"公共接口".
如果要由多个项目,可执行文件和/或服务共享它们,我认为将它们放入单独的程序集中是公平的.
但是,如果它们仅供内部使用并且为了您的方便,您可以选择将它们保存在与实现相同的组件中,从而使组件的总量相对较低.