问题描述
我们受到建议的轰炸,总是编程到接口而不是实现,以减少依赖性。我可以看到它的好处,并且在一个单独的项目中,我使用这种技术在适当的地方解耦。但是,当你想要分离两个单独的项目时会发生什么?
想象一下,你有两个独立的库, 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
推荐答案
这篇关于在哪里定义接口的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!