在哪里定义接口 [英] Where to Define Interfaces

问题描述

我们受到建议的轰炸，总是编程到接口而不是实现，以减少依赖性。我可以看到它的好处，并且在一个单独的项目中，我使用这种技术在适当的地方解耦。但是，当你想要分离两个单独的项目时会发生什么？



想象一下，你有两个独立的库， LibA 和 LibB 。您不希望任何一个库了解另一个库，但是，当您在客户端应用程序中使用它们时，您希望 LibA 能够在中调用函数LibB 的。当我遇到这个问题时，我想，''哦，我会使用界面'，但后来我遇到了在哪里定义这个问题。



如果我把它放在 LibA 中，那么，为了 LibB 能够实现它，它依赖于 LibA 。客户端应用程序可以定义它，但是我必须将代码复制粘贴到需要相同功能的任何其他应用程序中。



有一个第三个选项 - 在自己的单独项目/程序集中创建接口。这样做，但似乎用锤子来破解坚果。



有人可以提供任何建议吗？我是否陷入了错误的思维模式？我应该看一些完全不同的东西吗？感谢所有的建议。



亲切的愿望~Patrick

Hi,

We are bombarded by advice always to program to an interface, rather than an implementation, to reduce dependencies. I can see the benefits of this, and within an individual project, I use this technique to decouple classes wherever appropriate. But, what happens when you want to decouple two separate projects?

Imagine you have two separate libraries, LibA and LibB. You don''t want either library to ''know'' about the other, but, when you use them in a client application, you want LibA to be able to call a function in LibB. When I came across this problem, I thought, ''Oh, I''ll use an interface,'' but then I came upon the problem of where to define this.

If I put it in LibA, then, for LibB to be able to implement it, it becomes dependent upon LibA. The client application could define it, but then I would have to do a copy-paste of the code into any other applications that needed the same functionality.

There is a third option - creating the interface in a separate project/assembly of its own. This does the job, but seems like using a hammer to crack a nut.

Can anyone offer any advice on this? Am I stuck in the wrong mode of thinking? Should I be looking at something completely different? All advice gratefully received.

Kind wishes ~ Patrick

推荐答案

请看我对这个问题的评论;声明不清楚......



首先，我希望LibA和LibB你的意思是集会。实际上，每个.NET程序集都是一个库，即使它被命名为* .EXE（如果你仍然没有得到它）​​;并且有些情况甚至* .EXE应该是引用的程序集。 （这不是一种非常常用的技术，但它是非常合理的;我可以解释为什么如果你真的好奇可以使用它，但这个主题与这个问题无关。）



然后，你需要明白没有奇迹这样的事情。如果您使用某个接口，要么通过接口引用来实现它的使用，您需要定义它。它可以在使用程序集中或任何引用的程序集中定义。当然，如果两个接口在文本上相同但在不同的程序集中定义，则有不同的接口，不能互换使用;此外，这些定义会违反非常基本的 DRY 原则（ http://en.wikipedia.org / wiki / Don％27t_repeat_yourself [ ^ ] ）;所以，让我们忘记这种情况，并假设每个接口只有一个定义。顺便说一下，在运行时动态加载程序集会改变依赖项的特性，但不会改变上述事实。这就是你现在需要知道的全部内容。



现在，让我们按照简单的逻辑。成像你有两个装配使用的接口 IMy 。这意味着应该在某处定义。正如你所正确指出的那样，在LibA中定义它将使LibB依赖于LibA，反之亦然。在许多情况下，您确实需要这种依赖。这一切都取决于程序集的语义。是的，有些情况下，这两个组件都不应该依赖于另一个组件。在这种情况下，应用相同的原则没有奇迹这样的东西，我们得出唯一剩下的解决方案： IMy 应该在另一个程序集中定义，比方说， 接口，然后LibA和LibB程序集都应该引用它。就这么简单。



我必须注意，所有逻辑都适用于任何类型的定义;接口没有特定的东西。也就是说，您可能会错过接口在代码体系结构和依赖关系中的角色。您应该执行以下操作：考虑接口，它们的实现和使用而不用担心程序集。

关于依赖项，请查看这些设计模式：

http://en.wikipedia.org/wiki/Dependency_injection [ ^ ]，

http://en.wikipedia.org/wiki/Dependency_inversion_principle [ ^ ]。



一种非常有效的方法，使架构首先考虑.NET类型的依赖关系，何时图片或多或少清晰，考虑将代码分配到不同的程序集中。嗯，作为一个经验法则。这是因为程序集之间的依赖关系是类型之间依赖关系的产物，反之亦然，因为从开发过程的角度来看，.NET程序集之间的界限非常轻。换句话说，如果将一些代码从一个程序集移动到另一个程序集，并相应删除和添加程序集引用，它就不会改变使用和依赖代码甚至一点。

-SA

Please see my comment to the question; the statement is not clear…

First of all, I hope that by LibA and LibB you mean the assemblies. Actually, every .NET assembly is a library, even if it is named *.EXE (in case you still did not get it); and there are cases when even *.EXE should be a referenced assembly. (This is not a very usual technique, but it is quite legitimate; I can explain why it can be used if you are really curious, but this topic is unrelated to the question.)

Then, you need to understand that there is no such thing as a miracle. If you use some interface, either for implementing it of for using objects by interface reference, you need to have it defined. It can be defined in your using assembly or in any referenced assembly. Of course, if two interfaces are textually identical but are defined in different assemblies, there are different interfaces and cannot be used interchangeably; besides, such definitions would violate the very fundamental DRY principle (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself[^]); so, let''s forget such cases and assume that there is only one definition of each interface. By the way, loading assemblies dynamically during runtime changes the character of dependencies but not the facts stated above. This is all you need to know at the moment.

Now, let''s follow the simple logic. Imaging you have some interface IMy used by both your assemblies. It means that is should be defined somewhere. Defining it in LibA will make LibB dependent of LibA and visa versa, as you correctly pointed out. In many cases, you really need this dependency. It all depends on the semantic of the assemblies. And yes, there are cases when none of these two assemblies should depend on the other one. In this case, applying the same principle "there is no such thing as a miracle", we come to the only remaining solution: IMy should be defined in another assembly, say, "Interfaces", and then both LibA and LibB assemblies should reference it. As simple as that.

I must note that all the logic is applicable to absolutely any kind of definition; there is nothing specific to interfaces. That said, you might miss the role of interfaces in the architecture of the code and the dependencies. You should do the following: think of interfaces, their implementation and uses without any concern about assemblies.
As to dependencies, please review these design patterns:
http://en.wikipedia.org/wiki/Dependency_injection[^],
http://en.wikipedia.org/wiki/Dependency_inversion_principle[^].

A really productive way of making the architecture is thinking on the dependencies of .NET types first, and when the picture is more or less clear, think about distribution of the code into different assemblies. Well, as a rule of thumb. This is because the dependencies between assemblies is the product of dependency relationships between type, not visa versa, and because the boundaries between .NET assemblies are very light-weight, from the standpoint of development process. In other words, if you move some code from one assembly to another, with corresponding removal and adding of the assembly references, it won''t change the using and depending code even a bit.

—SA

使用Visual Studio？您可以在自己的文件中定义接口（可能在其中一个项目中），然后使用Add | Existing ... | As link将其添加到任何其他需要它的项目中。

With Visual Studio? You can define the interface in its own file (perhaps in one of the projects) then use "Add | Existing... | As link" to add it to any other projects that need it.

这篇关于在哪里定义接口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！