我们为啥要使用接口？仅仅是为了标准化吗？ [关闭]

Posted 2023-02-22

技术标签:

【中文标题】我们为啥要使用接口？仅仅是为了标准化吗？ [关闭]【英文标题】：Why do we use Interface? Is it only for Standardization? [closed]我们为什么要使用接口？仅仅是为了标准化吗？ [关闭] 【发布时间】：2011-01-02 19:41:23 【问题描述】：

我们为什么要使用接口？

只是为了标准化吗？

【问题讨论】：

而不是...？接口有很多用途... 我真的希望人们不要在非 c# 特定的帖子上放置 c# 之类的标签。这是一个非常好的问题，我可能错过了，因为 c# 是一个被忽略的标签。 【参考方案1】：

接口的用途

创建松散耦合的软件支持design by contract（实现者必须提供整个接口）允许使用可插拔软件允许不同的对象轻松交互相互隐藏类的实现细节促进软件的重用

类比1：很像美国的航天飞机，俄罗斯的联盟号飞船和中国的神舟五号都可以对接国际空间站，因为它们实现了相同的对接接口。（这只是一个例子——我不知道这在现实生活中是否属实，但为了一个例子，让我们暂停我们的怀疑）

类比 2：就像您可以将各种计算机显示器插入家用计算机一样。您可以将壁挂式电视、旧 CRT（较厚的那种）、20 英寸纯平屏幕或盲人盲文机插入其中以通过触摸“看到”。这些不同/不同的设备和您的计算机，因为他们都同意接口标准。

Details of C# interfaces -- 使用 C#/OOP 接口，您可以做同样的事情，但在看不见的/虚拟世界中。

您对标准化是正确的，但灵活性、可扩展性、可扩展性、可维护性也是正确的、可重用性、可测试性和能力。

（您使用软件界面的次数越多，这些“流行语”就会被理解得越多。并且始终考虑现实世界中的界面，因为它们对我们同样出色。）

【讨论】：

你遗漏了我最喜欢的接口用法：可测试性。如果我有两个类，A & B，并且 A.foo 调用 B.bar，那么只要 B 实现了一个接口并且可以“注入”到 A 中，那么我可以使用 mock、fake 或 stub 类来代替真正的 B。当 A.foo 根据 B.bar 的返回值改变其行为时，这尤其有用。（假设 B.bar 返回一个布尔值。A.foo 可能有一个带有 else 子句的 if(B.bar) 语句。）在 B 中使用接口允许我创建 mockB、fakeB 和/或 stubB，这允许我测试什么当 B.bar 返回 true 或 false 时发生。 @Alan R -添加了可测试性。谢谢。公认的答案是 TOP 的东西，看到这个概念没有被丢弃，因为大多数框架设计指南材料无法解释或理解它，这令人耳目一新。只是补充一点，如果你认真使用泛型，我不知道没有它们你是怎么过的。 +1 standardization, but also flexibility, scalability, extensibility, maintainability, reusability, testability and power.【参考方案2】：

接口用于描述实现的事物可以做什么。因此，您可以将实现相同接口的多个对象视为该接口的一种类型。

例如：

public interface IMyInterface
    public void DoFirst();
    public int DoSecond();



public class A : IMyInterface
   //class has to implement DoFirst and DoSecond
   public void DoFirst()
     Console.WriteLine("Blubb1");  
   

   public int DoSecond()
     Console.WriteLine("Blubb2");
     return 2;  
   


public class B : IMyInterface
   //class has to implement DoFirst and DoSecond
   public void DoFirst()
     Console.WriteLine("Blibb1");  
   

   public int DoSecond()
     Console.WriteLine("Blibb2");  
     return 4;

类以多种方式实现接口。但是您可以将它们用作 IMyInterface。例如：

public static void DoMethodsInInterface(IMyInterface inter)
    inter.DoFirst();
    inter.DoSecond();



public static void main()

   DoMethodsInInterface(new A());
   DoMethodsInInterface(new B());
   //Or use it in a List
   List<IMyInterface> interlist = new List<IMyInterface>();
   interlist.Add(new A());
   interlist.Add(new B());
   foreach(IMyInterface inter in interlist)
      inter.DoFirst();

我希望这能说明接口为什么有用。

【讨论】：

这个问题与一个问题相关联，该问题询问为什么要使用接口而不是简单地让成员执行适当的功能等，并且您的答案最接近回答那个问题。如果两个不相关的类都有一个方法Woozle，任何想要接受对任一类和Woozle的引用的代码都必须知道它正在处理哪个类，并且只能Woozle对其进行分类知道。相比之下，如果两个类都实现了IWoozler，那么给出任何IWoozler 的代码就可以Woozle 它而无需知道它的确切类型。这个答案比我见过的任何一个都更准确。这都是关于一个对象可以做什么。接口指定了一组与对象相关的操作，而不规定在这些操作中会发生什么，这些操作显然是特定于对象的。【参考方案3】：

它是用于接口的:)，这样你就可以在东西之间进行接口，当你有的时候它很有用

相同内容的多个实现当您将一个接口应用于多个不同的类时，因为您需要某种约定，这些类将能够做一些事情或具有一些功能

【讨论】：

【参考方案4】：

这是高级视图...

接口在Information Hiding 的概念中扮演着重要角色。

它们基本上可以帮助您隐藏类的实现细节，这样调用类就不会依赖于该实现。因此，通过使用接口，您可以在不更改调用类的情况下修改实现。这一切反过来限制了代码的复杂性，并使其更容易维护从长远来看。

当我第一次开始理解接口时，他们被解释为“提供类描述的合同”。不确定这是否会对您有所帮助，但如果您想到汽车的界面，您可以说它驱动、休息和转弯。所以只要它让我从 A 点到 B 点，我真的不需要知道这些功能是如何实现的。

【讨论】：

【参考方案5】：

在 C#/Java 等语言中使用接口的主要原因是这些语言不支持多重（类）继承（请参阅What is the exact problem with multiple inheritance?）。

但允许多个（接口）实现允许以不同方式使用类。

【讨论】：

托管语言中的接口不能替代多重继承。而且，即使在支持多重继承的语言中，无实现接口的概念也是相关且有用的。（参见依赖注入。） -1 没有经过深思熟虑，或者你真的不懂 C# 或 Java？我想说的是，在 C++ 中，可以使用纯抽象类来代替接口。大多数你可以在 Java/C# 中使用接口完成的事情，你可以在 C++ 中使用纯抽象类完成。在 C++ 中，如果您希望一个类具有多种行为，您将继承多个纯抽象类。但是你不能在 Java/C# 中做到这一点。我并不是说接口没有“用处”，我说的不止这些：如果没有多重接口继承，像 Java 和 C# 这样的语言就不会真正成为面向对象的编程语言。（它们不允许多类继承或混合） +1 这基本上是通过 C# 和 Java 的经验发现的。如果您试图通过避免多重继承来简化，那么您只会在其他地方创建复杂性。由于缺乏统一的底层方法，最终会变得更复杂。请参阅 C# Programming Language 3rd Edition, 1.9 Interfaces 中的 Krzystof Cwalina 的注释，其中说明了这一点。到目前为止，C# 和 Java 中仍然存在未解决的问题，如果允许类的多重继承，这些问题将有简单的解决方案。 -1 继承和接口真的很不一样。【参考方案6】：

界面有些尴尬。他们只相信同一个名字和实现的接口就意味着同一个行为，就支持契约式设计。这要归功于 API 文档，它必须经过人工检查。这使得接口太弱了。解决这个问题的一种方法可能是正式规范。另一方面，接口太强大，太严格。你不能发展经常妨碍重用的接口。这是通过协议解决的 - 动态语言中的机制，它发送消息（调用方法），当接收者不支持该消息时，调用标准回调。拥有带有约束的具体协议会更好。

【讨论】：

【参考方案7】：

想想remoting...

这里涉及到一个客户端和一个服务器。可以说它们在物理上被互联网分开。客户端正在调用一个实际执行发生在服务器上的方法。从客户端的角度来看，客户端对执行执行的服务器中的对象一无所知。但是它知道要调用什么方法。因为在构建客户端程序时，我们只接触到一个接口（或契约）。我们没有接触到实际存在于服务器上的整个对象。尝试在 .net remoting 中做一些演示应用程序，剩下的你就知道了。快乐编程。

【讨论】：

【参考方案8】：