接口与类实现在不同的项目中分离？ [英] Interfaces separated from the class implementation in separate projects?

问题描述

我们从事一个中等规模的项目（3个开发人员超过6个月），需要作出以下决定：我们希望将接口与具体实现分开。第一个是将界面存储在一个单独的文件中。

我们想进一步分析数据：我们希望有一个项目（CSPROJ）在一个.CS文件中加上另一个。 CS文件与帮助类（像这个接口中使用的一些公共类，一些枚举等）。然后，我们想要一个工厂模式的项目（CSPROJ），具体的接口实现和其他工人类。

任何想要创建实现此接口的对象的类都必须包含包含接口和公共类的第一个项目，而不是实现本身。

这个解决方案有一个很大的缺点：它将程序集数量乘以2，因为你将为每个正常项目一个具有interace的项目和一个实现的项目。

你会推荐什么？你认为将所有接口放在一个独立的项目中而不是其自己的项目中的一个接口是个好主意？

解决方案

我将区分这样的接口：

1. 独立接口，您可以在不谈论您的项目的其余部分。将它们放在一个专用的接口程序集中，这可能是您项目中所有其他程序集引用的。典型示例： ILogger ， IFileSystem ， IServiceLocator p>




2. 类耦合接口，这只是在项目类的上下文中才有意义。将它们放在与他们耦合的类的组件中。

   
   
   

   一个例子：假设你的域模型有一个香蕉类。如果您通过 IBananaRepository 接口检索香蕉，则该界面与香蕉紧密耦合。在不了解香蕉的东西的情况下，不可能实现或使用界面。因此，界面与 Banana 相同的程序集是合乎逻辑的。

   
   
   

   前面的例子有一个技术耦合，但耦合可能只是一个逻辑的。例如，即使接口声明没有， IFecesThrowingTarget 接口也许只能作为 Monkey 类的协作者技术链接到 Monkey 。

我的答案取决于可以将一些耦合到类可以这样做的概念。在界面后隐藏 将是一个错误。 有时可以只是新建一个类，而不是通过工厂注入或创建它。

We work on a middle-size project (3 developers over more than 6 months) and need to make following decision: We'd like to have interfaces separated from concrete implementation. The first is to store the interface in a separate file.

We'd like to go further and separate the data even more: We'd like to have one project (CSPROJ) with interface in one .CS file plus another .CS file with help classes (like some public classes used within this interface, some enums etc.). Then, we'd like to have another project (CSPROJ) with a factory pattern, concrete interface implementation and other "worker" classes.

Any class which wants to create an object implementing this interface must include the first project which contains the interfaces and public classes, not the implementation itself.

This solution has one big disadvantage: it multiplies the number of assemblies by 2, because you would have for every "normal" project one project with interace and one with implementation.

What would you recommend? Do you think it's a good idea to place all interfaces in one separate project rather than one interface in its own project?

解决方案

I would distinguish between interfaces like this:

1. Standalone interfaces whose purpose you can describe without talking about the rest of your project. Put these in a single dedicated "interface assembly", which is probably referenced by all other assemblies in your project. Typical examples: ILogger, IFileSystem, IServiceLocator.

2. Class coupled interfaces which really only make sense in the context of your project's classes. Put these in the same assembly as the classes they are coupled to.

   An example: suppose your domain model has a Banana class. If you retrieve bananas through a IBananaRepository interface, then that interface is tightly coupled to bananas. It is impossible to implement or use the interface without knowing something about bananas. Therefore it is only logical that the interface resides in the same assembly as Banana.

   The previous example has a technical coupling, but the coupling might just be a logical one. For example, a IFecesThrowingTarget interface may only make sense as a collaborator of the Monkey class even if the interface declaration has no technical link to Monkey.

My answer does depend on the notion that it's okay to have some coupling to classes. Hiding everything behind an interface would be a mistake. Sometimes it's okay to just "new up" a class, instead of injecting it or creating it via a factory.

这篇关于接口与类实现在不同的项目中分离？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！