Question

好的，所以我决定开始在我的代码库中使用接口，这对于某些任务来说非常好。例如，我有一个实现IUrlBuilder的URL构建器类，现在实现并不重要。很棒，但以此界面为例。

namespace SproutMessagingFramework.Webtext.Interfaces
{
using System.Net;

public interface ICookieJar
{
    CookieCollection Collection { get; set; }
    CookieContainer Container { get; set; }

    void AddResponse(HttpWebResponse Response);
    void AddResponse(HttpWebResponse Response, string Path, string Domain);
}
}

在我看来，这个界面非常具体，这两个方法除了具体类已经做的事情之外不会做太多其他事情。那我为什么要把它变成一个界面呢？我的想法是，如果我需要更改AddResponse的实现？

这是正确的还是我只是膨胀代码库？

Answer 1

接口可以设计为与特定类别1：1的对应关系。这允许（除其他外）与模拟框架的集成，在这里您可以在假设测试环境中验证cookie怪物的行为时，将假装的cookie jar替换为真实的cookie。

然而，更常见的是，接口定义类的功能的子集，并且通常可以与类本身正交。正交接口的一个很好的例子是IDisposable。当一个类想要支持非托管资源（如套接字，文件描述符等）的干净回收时，它实现了IDisposable，尽管资源清理不是该类实际设计的目的。

另一个常见用途是提供统一的容器模型，例如ICollection和IEnumerable。

最后，类通常实现几个接口，通常对应于其功能的正交截面。

Answer 2

即使只有一种方法可以自己实现AddResponse方法，我仍然可以想象ICookieJar的实现在将调用转发给接口的某个具体实例之前做了些什么。

例如，添加诊断日志记录的实现，或者在存储时透明地重命名cookie的实现。

基于接口的编程，我做得对吗？

2 个答案: