c# - 在 C# 中使用接口(interface)有哪些优点?

标签 c# oop interface design-patterns

几年前在工作中被迫进入一个软件项目,被迫快速学习C#。我的编程背景很薄弱(经典 ASP)。

这些年来我学到了很多东西,但由于我学习 C# 的方式的强制性,有很多我不清楚的基本概念。

具体来说,一个接口(interface)。我了解基础知识,但在编写应用程序时,我很难弄清楚一个应用程序的实际用途。为什么要为他们的应用程序编写一个界面?

谢谢 凯文

最佳答案

界面说明了某些东西应该如何工作。将其视为契约(Contract)或模板。它是控制反转或依赖注入(inject)等事情的关键。

我使用 Structure Map 作为我的 IoC 容器。这允许我为我的所有类定义一个接口(interface)。你可能会说的地方

Widget w = new Widget();

我会说

IWidget w = ObjectFactory.GetInstance<IWidget>();

这是非常强大的,因为我的代码并不一定说明 Widget 的真正含义。它只是根据 IWidget 的接口(interface)知道一个 Widget 可以做什么。

它有一些强大的功能,因为现在我正在使用 IoC 容器,我可以做一些更漂亮的事情。在我需要使用 Widget 的单元测试中,我可以为 Widget 创建一个模拟。所以说我的 Widget 通过连接到数据库或 Web 服务来做一些非常强大的事情,我的 mock 可以模拟连接到这些资源并返回 stub 数据给我。这使我的测试运行得更快并且以更可靠的方式运行。因为我正在使用 StructureMap,所以我可以告诉 StructureMap 在我的代码的生产使用期间加载我的 Widget 的真实实现,并在测试期间以编程方式或通过配置加载 Widget 的模拟版本。

此外,因为我使用的是 IoC 容器,所以我可以为我的应用程序提供很酷的新功能,例如编写三种不同的方式来缓存数据。我可以使用 Lucene.NET 等工具为本地缓存创建一个本地开发人员框缓存。我可以让开发服务器使用在一个盒子上运行良好的 .NET 缓存。然后我可以为我的生产服务器提供第三个选项,使用缓存层,例如 MemCache Win32 或 Velocity。只要所有三个缓存实现都符合相同的接口(interface),它们的实际实现根本不关心我(或我的代码)。我只是让 StructureMap 去获取当前的环境实现,然后开始工作。

如果您完全遵循依赖注入(inject),那么接口(interface)在这里也可以派上用场,IoC 容器例如 StructureMap,因为我可以在我的类的构造函数中通过接口(interface)声明类的使用。

public class Widget(IWidgetRepository repository, IWidgetService service) : IWidget
{
    //do something here using my repository and service
}

然后当我通过像这样的 StructureMap 新建一个 Widget 实例时

IWidget widget = ObjectFactory.GetInstance<IWidget>();

请注意,我没有在构造函数中指定存储库或服务。 StructureMap 通过构造函数中指定的接口(interface)知道如何获取适当的实例并将它们也传递进来。这使得代码非常强大和干净!

所有这些都来自接口(interface)的简单定义和一些巧妙的用法!

关于c# - 在 C# 中使用接口(interface)有哪些优点?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1035632/

相关文章:

c# - 初始化中的ThreadState异常

c# - 如何以编程方式从 Google 云端硬盘中的 "share with me"中删除文件

c# - 如何读取 Excel 文件?

java - 是在编译时还是运行时检查访问权限?

javascript - 是什么使这两个函数分别为 'public' 和 'private',这意味着什么?

c# - 来自 C5 Generic Collection Library 的小型集合相对来说非常慢 - 有什么办法吗?

java - 我无法正确打印我的卡片对象

java - 如何为类和方法创建自定义注解?

java - 如何在 Java 中定义一个接口(interface)方法来接受一个类或其任何子类?

Java:在任何接口(interface)定义中强制(隐式)声明对象方法背后的推理