关于c#:我如何知道何时构建自己的接口

How Can I Learn when to build my own Interfaces

本问题已经有最佳答案,请猛点这里访问。

Possible Duplicates:
Interfaces: Why can’t I seem to grasp them?
How will I know when to create an interface?

我正在使用C,我知道接口是什么,以及如何在语法上使用它们,等等。但我还没有学到的是,当我被指派编写一个项目时,创建一个组件……我应该如何更好地学习接口,所以当我想做一些事情时,我可以考虑在我的设计中使用它们……或者例如,我想学习依赖注入,甚至使用模拟对象进行测试,这些都与对接口的良好理解有关,并且知道何时以及如何使用它们……你能不能给我一些好的建议,阅读…那能帮我吗?


当您有几个可以执行一组常见操作的东西时,请使用接口。它们如何执行这些操作可能是不同的,但是当使用类时,它们的行为是相同的。

一个好的现实世界例子就像是一个网络驱动器和一个普通的硬盘驱动器。无论哪种方式,都可以执行基本的文件操作。它们的实际操作方式是不同的,但大多数情况下,当您想在驱动器上执行某项操作时,您不在乎它是网络驱动器还是物理驱动器。这是一个接口。

在硬件方面,不同的键盘设计不同,它们(可能)在不同的位置有按钮,但这些对计算机来说都无关紧要。计算机对键盘界面的视图是相同的,而不管它发送按键之外的任何方面。


如果这些东西要以相同的方式使用,它们必须具有什么共同的接口?

如果你能回答这个问题,那么你就可以在现实生活中正确地设计和使用界面了。


如果使用类似TDD的工作流,则通常使用接口来定义一个对象对另一个对象的需求,该对象最终将使用另一个对象。以这种方式使用接口允许它们在应用程序中创建"接缝",在应用程序中可以替换/插入逻辑/etc。

以这种方式考虑接口的一种方法是将对象视为互相发送消息,并且接口是可以发送的消息的定义。


我发现理解如何在插件架构中使用接口非常有用。

有很多链接,例如:http://www.codeproject.com/kb/cs/c_uu plugin_architecture.aspx

试着想象一下,在不使用接口的情况下,您如何编写这种体系结构——然后您可能会完全理解它们带来了什么。


接口的目标是减少应用程序组件之间的耦合。通过使用接口,您将绑定到契约而不是实现。这意味着,只要遵循相同的合同,您可以根据自己的需要更改实现。

例如,使用IList而不是List,这被认为是一种良好的实践,因为IList只说明您需要一些类似于列表的东西。这样,就可以在不影响代码的情况下替换列表的其他实现。(例如,对象映射和数据访问库nhibernate使用它来允许延迟加载集合。)

接口的最佳候选类是与外部系统(文件系统、数据库、网络、Web服务等)交互的类。如果您在代码中直接使用这些系统,那么测试和重构将出现问题。

我个人认为接口在依赖注入和测试场景中特别有用。因为您已经了解了什么是接口,所以应该能够理解依赖注入。阅读这些概念将有助于您识别接口的良好候选者。

这真的是一个你学会用经验的东西。