"编程到界面"是什么意思？

我以前给学生的具体例子是他们应该写作

List myList = new ArrayList(); // programming to the List interface

代替

ArrayList myList = new ArrayList(); // this is bad

这些在短程序中看起来完全相同,但如果你继续myList在你的程序中使用100次,你可以开始看到差异.第一个声明确保您只调用接口myList定义的方法List(因此没有ArrayList特定的方法).如果您已经通过这种方式编程到界面,稍后就可以确定您确实需要

List myList = new TreeList();

而且你只需要改变那个地方的代码.您已经知道,由于您已编程到接口,因此更改实现时,其余代码不会执行任何操作.

当你谈论方法参数和返回值时,好处更明显(我认为).以此为例:

public ArrayList doSomething(HashMap map);

该方法声明将您与两个具体实现联系起来(ArrayList和HashMap).一旦从其他代码调用该方法,对这些类型的任何更改可能意味着您还必须更改调用代码.编程到接口会更好.

public List doSomething(Map map);

现在,List返回什么样的类型或者Map作为参数传递什么样的类型并不重要.您在doSomething方法内所做的更改不会强制您更改调用代码.

对界面进行编程时说:"我需要这个功能,而我并不关心它来自哪里."

考虑(在Java中),该List接口与在ArrayList和LinkedList具体的类.如果我关心的是我有一个包含多个数据项的数据结构,我应该通过迭代访问,我会选择一个List(这是99%的时间).如果我知道我需要从列表的任何一端插入/删除常量时间,我可能会选择LinkedList具体的实现(或者更可能是使用Queue接口).如果我知道我需要通过索引随机访问,我会选择ArrayList具体的类.

除了删除类之间不必要的耦合之外,使用接口是使代码易于测试的关键因素.通过创建定义类的操作的接口,您允许希望使用该功能的类能够使用它而无需直接依赖于您的实现类.如果您稍后决定更改并使用其他实现,则只需更改实例实例化的代码部分.其余代码无需更改,因为它取决于接口,而不是实现类.

这在创建单元测试时非常有用.在被测试的类中,您依赖于接口并通过构造函数或属性settor将接口实例注入类(或允许它根据需要构建接口实例的工厂).该类在其方法中使用提供的(或创建的)接口.当您编写测试时,您可以模拟或伪造接口,并提供一个响应单元测试中配置的数据的接口.您可以这样做,因为您所测试的类仅处理接口,而不是您的具体实现.任何实现该接口的类(包括您的模拟或假类)都可以.

编辑:下面是一篇文章的链接,其中Erich Gamma讨论了他的引用,"程序到界面,而不是实现."

http://www.artima.com/lejava/articles/designprinciples.html

你应该研究控制反转:

Martin Fowler:控制容器的反转和依赖注入模式

维基百科:控制倒置

在这种情况下,你不会写这个:

IInterface classRef = new ObjectWhatever();

你会写这样的东西:

IInterface classRef = container.Resolve();

这将进入container对象中基于规则的设置,并为您构造实际对象,可以是ObjectWhatever.重要的是,你可以用完全使用其他类型对象的东西替换这个规则,你的代码仍然可以工作.

如果我们将IoC从表中删除,您可以编写代码,该代码知道它可以与执行某些特定操作的对象进行通信,但不能使用哪种类型的对象或如何进行操作.

传递参数时这会派上用场.

至于你的括号问题"另外,你怎么能写一个接受一个实现接口的对象的方法？这可能吗？",在C#中你只需要使用参数类型的接口类型,如下所示:

public void DoSomethingToAnObject(IInterface whatever) { ... }

这直接插入"与特定事物的对象交谈".上面定义的方法知道对象的期望,它实现了IInterface中的所有内容,但它并不关心它是哪种类型的对象,只是它遵守契约,这就是接口.

例如,你可能熟悉计算器,并且可能在你的日子里使用了很多,但大多数时候它们都是不同的.另一方面,您知道标准计算器应该如何工作,因此您可以全部使用它们,即使您不能使用每个计算器都没有的特定功能.

这是界面之美.你可以写一段代码,知道它会传递给它的对象,它可以期望某些行为.它并不关心它是什么类型的对象,只是它支持所需的行为.

让我举一个具体的例子.

我们为Windows窗体提供了一个定制的翻译系统.该系统循环访问表单上的控件并在每个表单中翻译文本.系统知道如何处理基本控件,比如控件类型有文本属性,以及类似的基本内容,但对于任何基本控件,它都不足.

现在,由于控件继承自我们无法控制的预定义类,我们可以做以下三件事之一:

为我们的翻译系统构建支持,以专门检测它正在使用哪种类型的控件,并翻译正确的位(维护噩梦)

在基类中构建支持(不可能,因为所有控件都从不同的预定义类继承)

添加界面支持

所以我们做了nr.3.我们所有的控件都实现了ILocalizable,这是一个为我们提供一种方法的接口,即将"自身"转换为翻译文本/规则容器的能力.因此,表单不需要知道它找到了哪种控件,只需知道它实现了特定的接口,并且知道有一种方法可以调用本地化控件.

对接口进行编程与我们在Java或.NET中看到的抽象接口完全无关.它甚至不是OOP概念.

它的真正含义是不要乱搞对象或数据结构的内部.使用抽象程序接口或API与您的数据进行交互.在Java或C#中,这意味着使用公共属性和方法而不是原始字段访问.对于C,这意味着使用函数而不是原始指针.

编辑:对于数据库,它意味着使用视图和存储过程而不是直接表访问.

接口的代码并非实现与Java及其接口构造无关.

这个概念在"图案/四人帮"中引人注目,但很可能在此之前就已经存在.在Java出现之前,这个概念确实存在.

创建Java接口构造是为了帮助这个想法(除其他外),人们已经过于专注于构造作为意义的中心而不是原始的意图.但是,这就是我们在Java,C++,C#等中使用公共和私有方法和属性的原因.

它意味着只与对象或系统的公共接口进行交互.不要担心,或者甚至预测它是如何做到内部的.不要担心它是如何实现的.在面向对象的代码中,这就是我们拥有公共方法/私有方法/属性的原因.我们打算使用公共方法,因为私有方法只在内部使用,在类中.它们构成了类的实现,可以根据需要进行更改,而无需更改公共接口.假设关于功能,每次使用相同的参数调用类时,类上的方法将执行相同的操作,并具有相同的预期结果.它允许作者改变类的工作方式及其实现,而不会破坏人们与之交互的方式.

您可以在不使用Interface构造的情况下编程到接口,而不是实现.您可以编程到接口而不是C++中的实现,它没有Interface构造.只要通过公共接口(契约)进行交互而不是在系统内部的对象上调用方法,就可以更加健壮地集成两个大型企业系统.在给定相同输入参数的情况下,接口应始终以相同的预期方式作出反应; 如果实现到接口而不是实现.这个概念在许多地方都有效.

摇晃Java接口与"接口程序而不是实现"概念有任何关系的想法.他们可以帮助应用这个概念,但它们不是概念.

听起来你理解界面是如何工作的,但不确定何时使用它们以及它们提供的优势.以下是界面何时有意义的几个示例:

// if I want to add search capabilities to my application and support multiple search
// engines such as Google, Yahoo, Live, etc.

interface ISearchProvider
{
    string Search(string keywords);
}

然后我可以创建GoogleSearchProvider,YahooSearchProvider,LiveSearchProvider等.

// if I want to support multiple downloads using different protocols
// HTTP, HTTPS, FTP, FTPS, etc.
interface IUrlDownload
{
    void Download(string url)
}

// how about an image loader for different kinds of images JPG, GIF, PNG, etc.
interface IImageLoader
{
    Bitmap LoadImage(string filename)
}

然后创建JpegImageLoader,GifImageLoader,PngImageLoader等.

大多数加载项和插件系统都在接口之外工作.

另一种流行的用途是存储库模式.假设我想加载来自不同来源的邮政编码列表

interface IZipCodeRepository
{
    IList GetZipCodes(string state);
}

然后我可以创建一个XMLZipCodeRepository,SQLZipCodeRepository,CSVZipCodeRepository等.对于我的Web应用程序,我经常在早期创建XML存储库,这样我就可以在Sql数据库准备好之前启动并运行.数据库准备好后,我编写一个SQLRepository来替换XML版本.我的其余代码保持不变,因为它从接口运行.

方法可以接受以下接口:

PrintZipCodes(IZipCodeRepository zipCodeRepository, string state)
{
    foreach (ZipCode zipCode in zipCodeRepository.GetZipCodes(state))
    {
        Console.WriteLine(zipCode.ToString());
    }
}

当您拥有类似的类集时,它使您的代码更具可扩展性并且更易于维护.我是一名初级程序员,所以我不是专家,但我刚刚完成了一个需要类似东西的项目.

我在客户端软件上工作,该软件与运行医疗设备的服务器通信.我们正在开发此设备的新版本,其中包含一些客户必须有时配置的新组件.有两种类型的新组件,它们是不同的,但它们也非常相似.基本上,我必须创建两个配置表单,两个列表类,两个一切.

我决定最好为每种控件类型创建一个抽象基类,它几乎包含所有实际逻辑,然后派生类型来处理两个组件之间的差异.但是,如果我不得不一直担心类型,那么基类就无法对这些组件执行操作(好吧,它们可能有,但是每个方法都会有"if"语句或开关) .

我为这些组件定义了一个简单的接口,所有基类都与这个接口通信.现在,当我改变某些东西时,它几乎"无处不在",我没有代码重复.

如果使用Java编程,JDBC就是一个很好的例子.JDBC定义了一组接口,但没有说明实现.您的应用程序可以根据这组接口编写.从理论上讲,您选择了一些JDBC驱动程序,您的应用程序就可以运行.如果您发现有更快或更好或更便宜的JDBC驱动程序或出于任何原因,您可以再次从理论上重新配置属性文件,而无需在应用程序中进行任何更改,您的应用程序仍然可以正常工作.

对接口进行编程非常棒,它促进了松耦合.正如@lassevk所提到的,控制反转是一个很好的用途.

另外,请查看SOLID主体.这是一个视频系列

它通过硬编码(强耦合示例)然后查看接口,最后进入IoC/DI工具(NInject)

那里有很多解释,但要使它更简单.举个例子来说List.可以使用as实现列表:

内部数组

链表

其他实施

通过建立一个界面,比如说List.您只对List的定义或List现实中的含义进行编码.

您可以在内部使用任何类型的实现来说明array实现.但是假设你希望改变实现,出于某种原因说出错误或性能.然后你只需要将声明更改List ls = new ArrayList()为List ls = new LinkedList().

在代码中没有其他地方,你是否必须改变其他任何东西; 因为其他一切都是建立在定义上的List.

我是这个问题的后来者,但是我想在这里提到"程序到界面,而不是实现"这一行在GoF(Gang of Four)设计模式书中有一些很好的讨论.

它说,在第.18:

编程到接口,而不是实现

不要将变量声明为特定具体类的实例.相反,只提交由抽象类定义的接口.你会发现这是本书设计模式的一个共同主题.

以上,它始于:

仅根据抽象类定义的接口操作对象有两个好处:

只要对象遵循客户期望的接口,客户端就不会意识到它们使用的特定对象类型.

客户端仍然不知道实现这些对象的类.客户端只知道定义接口的抽象类.

所以换句话说,不要把它写成你的类,以便它有一个quack()ducks 的方法,然后是一个bark()dog 的方法,因为它们对于类(或子类)的特定实现来说太具体了.相反,使用通常足以在基类中使用的名称来编写方法,例如giveSound()或move(),以便它们可以用于鸭子,狗,甚至汽车,然后你的类的客户端可以说.giveSound()而不是在发出要发送给对象的正确消息之前考虑是否使用quack()或bark()甚至确定类型.

除了已经选择的答案(以及此处的各种信息性帖子),我强烈建议您获取Head First Design Patterns的副本.这是一个非常简单的阅读,将直接回答您的问题,解释它为什么重要,并向您展示许多编程模式,您可以使用这些模式来使用该原则(和其他).

要添加到现有帖子中，当开发人员同时处理单独的组件时，有时对接口进行编码有助于大型项目。您需要做的就是预先定义接口并向其中编写代码，而其他开发人员则向要实现的接口编写代码。