标签：ret 相关 其它 关注 动物 coupling 显示 orm 没有
我记得我曾经在一篇帖子中提到过，一个接口可以从三方面去考察：
制定者（或者叫协调者），实现者（或者叫生产者），调用者（或者叫消费者）。
接口本质上就是由制定者来协调实现者和调用者之间的关系。
所以通常说的“面向接口编程”可以理解为：
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
---------------------
作者：yinhuaiya
来源：CSDN
原文：https://blog.csdn.net/yinhuaiya/article/details/42705591
版权声明：本文为博主原创文章，转载请附上博文链接！
接口描述：
接口，即对实现类的一种规范，当一个具体实现类实现这个接口的时候，应当实现接口所定义的所有规范。
那为什么要面向接口编程呢？
答案和使用spring是一样的，降低代码耦合度，提高可扩展性，即规范与实现分离。当我们要使用一个组件的时候，只是直接面向这个组件的接口，并不关心接口的具体实现，这样，当扩展或维护接口功能的时候，就不需要修改我们调用方的代码，实现调用方与接口实现的解耦
---------------------
作者：内心毫无波动甚至还想笑
来源：CSDN
原文：https://blog.csdn.net/yym836659673/article/details/74093069
版权声明：本文为博主原创文章，转载请附上博文链接！
下面是我对面向接口编程的理解
优点：
1.程序结构清晰，使用方便
2.接口经过合理设计后，有利于程序设计的规范化，并可以并行开发，提高工作效率
3.实现了程序的可插拔性，对于不同的需求切换不同的实现，降低了耦合度，随着系统复杂性的提高这个优势会越来越明显
4.允许多重实现，弥补了继承的缺陷
---------------------
作者：泊川
来源：CSDN
原文：https://blog.csdn.net/wantken/article/details/31763669
版权声明：本文为博主原创文章，转载请附上博文链接！
面向接口编程的好处
https://blog.csdn.net/lubiaopan/article/details/17140347
向接口编程就是面向抽象编程、面向规范编程，它带来的最大的好处便是解耦、增强扩展性、屏蔽变化
举例：非单例的情况，侧重于强调[扩展性强]
//命令接口
public interface ICommand{
void doCommand();
}
//命令1
public class Command1 implements ICommand{}
//命令2
public class Command2 implements ICommand{}
//命令执行器
public class CommandExecutor{
public void execute(ICommand command){
//略
}
}
//命令工厂
public class CommandFactory{
ICommand getCommand(string type){
//通过type查询配置文件，然后反射创建Command
}
}
public class Client{
public static void main(String args[]){
CommandFactory f=new CommandFactory();
ICommand c1 = f.getCommand("1");
ICommand c2 = f.getCommand("2");
CommandExecutor ce = new CommandExecutor();
c.execute(c1);
c.execute(c2);
}
}
CommandExecutor的execute方法不关心是传过来的是什么命令，只管执行。
增加新的命令实现类，对CommandExecutor没有任何影响。
举例二：单例时的情况 ，侧重于强调[屏蔽变化]
1、最最常见的DAO模式，程序运行的时候针对一个DAO接口只有一个实现存在于jvm中，这种情况下虽然在运行时无法实现接口和实现的一对多关系，但当某天需要针对另一种数据库进行移植的时候，只需要DAO的实现发生变化即可，调用DAO的Service层不用任何变化。
2、还有最最常用的Servlet，我们在编写自己的Servlet程序的时候，用的是HttpServletRequest接口和HttpResponse接口而不是具体的实现，那么我们的程序可以运行于Tomcat上，可以运行于Jetty上，可以运行于WebLogic上，而无需任何更改、变化。
---------------------
作者：lubiaopan
来源：CSDN
原文：https://blog.csdn.net/lubiaopan/article/details/17140347
版权声明：本文为博主原创文章，转载请附上博文链接！
为什么要使用面向接口编程？
最典型的例子是使用@autowired 一个接口对口。我们常常说要面向接口编程，似乎它是一种流行，一种规范，可是为什么要这么做，很多人就说不清楚了，网上也有很多这样的问题，我大概总结一下：
1. 一种规范约束
制定者（或者叫协调者），实现者（或者叫生产者），调用者（或者叫消费者）。
接口本质上就是由制定者来协调实现者和调用者之间的关系。
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
接口的语义是can-do语义，表约束(Constraint)。
像jdbc的规范api,不管你使用哪一套实现，我们使用的时候都是使用相同的api.
2. 分离设计与实现
使得系统可以支持开闭原则和依赖倒转原则。设计师可以设计出接口，而程序员可以依照接口去写实现。
3. 解耦合
在一定程度上解耦合，依赖接口还不依赖具体实现，在替换实现类的时候，可以将影响减到最小。
4. 方便做单元测试
在依赖接口的情况下，单元测试更容易，使用mock也更容易，在TDD中，测试驱动就是要让程序易于测试。
5. 与设计有关
在一个面向对象的系统中，系统的各种功能是由许许多多的不同对象协作完成的。
在这种情况下，各个对象内部是如何实现自己的对系统设计人员来讲就不那么重要了；
而各个对象之间的协作关系则成为系统设计的关键。
在OSGI规范中，接口与实现的分离是用得最淋漓尽致的。
6. Spring 的IOC
Spring将类的创建过程隐藏起来，实际上就是一个大的工厂，使得我们的代码更简洁，更易于管理和测试。
---------------------
作者：晨曦遇晓
来源：CSDN
原文：https://blog.csdn.net/u014508939/article/details/74312041
版权声明：本文为博主原创文章，转载请附上博文链接！
设计模式解析里提到了面向对象设计考虑的几个视角，一个是概念层，一个是规约层，一个是实现层。我如果没有猜错的话，实际上我们大多数人的眼睛一直是盯着实现层的，而这正是面向对象设计所极力避免的，即你不要在一开始就关注这些细节，你要关注的是规约（接口）.
对于实际项目开发来说，如果我们把实现的过程分为多个阶段的话我们不妨这么划分，第一阶段，根据client端的需要去设计我们的规约(interface),在这个阶段任何实现都没有，所有的任务就是定义接口所需要的职责，以及所需要的一些po,vo;第二阶段，实现前面定义的规约.
对面向接口编程的理解
https://blog.csdn.net/paul342/article/details/47272077
为什么要使用面向接口编程
https://blog.csdn.net/z_Dendy/article/details/22725539
关于面向接口编程
https://blog.csdn.net/u011212549/article/details/52351297
面向接口编程（很重要的一种编程思想）：
优点：
松耦合，可以达到类似于插座的效果（热插拨）。
制定者（或者叫协调者），实现者（或者叫生产者），调用者（或者叫消费者）。
接口本质上就是由制定者来协调实现者和调用者之间的关系。
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
接口的语义是can-do语义，表约束(Constraint)。
像jdbc的规范api,不管你使用哪一套实现，我们使用的时候都是使用相同的api.
---------------------
作者：晨曦遇晓
来源：CSDN
原文：https://blog.csdn.net/u014508939/article/details/74312041
版权声明：本文为博主原创文章，转载请附上博文链接！
在一个面向对象的系统中，系统的各种功能是由许许多多的不同对象协作完成的。在这种情况下，各个对象内部是如何实现自己的对系统设计人员来讲就不那么重要了；而各个对象之间的协作关系则成为系统设计的关键。小到不同类之间的通信，大到各模块之间的交互，在系统设计之初都是要着重考虑的，这也是系统设计的主要工作内容。面向接口编程我想就是指按照这种思想来编程吧！实际上，在日常工作中，你已经按照接口编程了，只不过如果你没有这方面的意识，那么你只是在被动的实现这一思想；表现在频繁的抱怨别人改的代码影响了你（接口没有设计到），表现在某个模块的改动引起其他模块的大规模调整（模块接口没有很好的设计）等等。
Booch先生那天谈到Interaction Designer，它就是指做这类设计的人，只不过层次更高一些。我想目前我们的软件设计队伍中，这类人是最缺乏的人才之一。
非接口编程？是不是就是面向过程的编程思想？
1.关于接口的理解。
接口从更深层次的理解，应是定义（规范，约束）与实现（名实分离的原则）的分离。
我们在一般实现一个系统的时候，通常是将定义与实现合为一体，不加分离的，我认为最为理解的系统设计规范应是所有的定义与实现分离，尽管这可能对系统中的某些情况有点繁烦。
接口的本身反映了系统设计人员对系统的抽象理解。
接口应有两类：第一类是对一个体的抽象，它可对应为一个抽象体(abstract class)；
第二类是对一个体某一方面的抽象，即形成一个抽象面（interface）；
一个体有可能有多个抽象面。
抽象体与抽象面是有区别的。
2.设计接口的另一个不可忽视的因素是接口所处的环境(context,environment)，系统论的观点：环境是系统要素所处的空间与外部影响因素的总和。任何接口都是在一定的环境中产生的。因此环境的定义及环境的变化对接口的影响是不容忽视的，脱离原先的环境，所有的接口将失去原有的意义。
3.按照组件的开发模型（3C），它们三者相辅相成，各司一面，浑然一体，缺一不可。
面向对象是指，我们考虑问题时，以对象为单位，考虑它的属性及方法
面向过程是指，我们考虑问题时，以一个具体的流程（事务过程）为单位，考虑它的实现
接口设计与非接口设计是针对复用技术而言的，与面向对象（过程）不是一个问题
我认为：UML里面所说的interface是协议的另一种说法。并不是指com的interface，CORBA的interface，Java的interface，Delphi的interface，人机界面的interface或NIC的interface。
在具体实现中，是可以把UML的interface实现为语言的interface，分布式对象环境的interface或其它什么 interface，但就理解UML的interface而言，指的是系统每部分的实现和实现之间，通过interface所确定的协议来共同工作。
所以我认为，面向interface编程，原意是指面向抽象协议编程，实现者在实现时要严格按协议来办。也就是Bill Joy同志说的，一边翻rfc，一边写代码的意思。面向对象编程是指面向抽象和具象。抽象和具象是矛盾的统一体，不可能只有抽象没有具象。一般懂得抽象的人都明白这个道理。 但有的人只知具象却不知抽象为何物。
所以只有interface没有实现，或只有实现而没有interface者是没有用的，反OO的。
所以还是老老实实面向对象编程，面向协议编程，或者什么都不面向，老老实实编程。
但是我很讨厌讨论这样的术语，不如我们谈谈什么叫面向领导的编程？面向用户的编程？领导和用户有时都很BT，我们就面向BT编程？
Dependency and Coupling
抽象层是规则的制定者
面向抽象机制编程；
抽象机制是规则的制定者；
接口代表可变的参与者。
面向接口编程的核心是：分离与可变。
面向标准编程。
https://blog.csdn.net/jj_nan/article/details/70161086
一个接口可以从三方面去考察：
制定者（或者叫协调者），实现者（或者叫生产者），调用者（或者叫消费者）。
接口本质上就是由制定者来协调实现者和调用者之间的关系。
所以通常说的“面向接口编程”可以理解为：只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
我记得我曾经在一篇帖子中提到过，一个接口可以从三方面去考察：
制定者（或者叫协调者），实现者（或者叫生产者），调用者（或者叫消费者）。
接口本质上就是由制定者来协调实现者和调用者之间的关系。
所以通常说的“面向接口编程”可以理解为：
只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。
---------------------
作者：yinhuaiya
来源：CSDN
原文：https://blog.csdn.net/yinhuaiya/article/details/42705591
版权声明：本文为博主原创文章，转载请附上博文链接！
优点：
接口和实现分离了，适于团队的协作开发。
主要为了实现松散耦合的系统，便于以后升级，扩展。
https://blog.csdn.net/hbcztutu/article/details/78860816
面向接口编程就是先把客户的业务逻辑线提取出来，作为接口，业务具体实现通过该接口的实现类来完成。
当客户需求变化时，只需编写该业务逻辑的新的实现类，通过更改配置文件(例如Spring框架)中该接口
的实现类就可以完成需求，不需要改写现有代码，减少对系统的影响。
https://blog.csdn.net/jj_nan/article/details/70161086
为什么要使用面向接口编程
https://blog.csdn.net/z_Dendy/article/details/22725539
对于各位使用面向对象编程语言的程序员来说，“接口”这个名词一定不陌生，但是不知各位有没有这样的疑惑：接口有什么用途？它和抽象类有什么区别？能不能用抽象类代替接口呢？而且，作为程序员，一定经常听到“面向接口编程”这个短语，那么它是什么意思？有什么思想内涵？和面向对象编程是什么关系？本文将一一解答这些疑问。
1.面向接口编程和面向对象编程是什么关系
首先，面向接口编程和面向对象编程并不是平级的，它并不是比面向对象编程更先进的一种独立的编程思想，而是附属于面向对象思想体系，属于其一部分。或者说，它是面向对象编程体系中的思想精髓之一。
2.接口的本质
接口，在表面上是由几个没有主体代码的方法定义组成的集合体，有唯一的名称，可以被类或其他接口所实现（或者也可以说继承）。它在形式上可能是如下的样子：
|
interface InterfaceName { void Method1(); void Method2(int para1); void Method3(string para2,string para3); } |
那么，接口的本质是什么呢？或者说接口存在的意义是什么。我认为可以从以下两个视角考虑：
1）接口是一组规则的集合，它规定了实现本接口的类或接口必须拥有的一组规则。体现了自然界“如果你是……则必须能……”的理念。
例如，在自然界中，人都能吃饭，即“如果你是人，则必须能吃饭”。那么模拟到计算机程序中，就应该有一个IPerson（习惯上，接口名由“I”开头）接口，并有一个方法叫Eat()，然后我们规定，每一个表示“人”的类，必须实现IPerson接口，这就模拟了自然界“如果你是人，则必须能吃饭”这条规则。
从这里，我想各位也能看到些许面向对象思想的东西。面向对象思想的核心之一，就是模拟真实世界，把真实世界中的事物抽象成类，整个程序靠各个类的实例互相通信、互相协作完成系统功能，这非常符合真实世界的运行状况，也是面向对象思想的精髓。
2）接口是在一定粒度视图上同类事物的抽象表示。注意这里我强调了在一定粒度视图上，因为“同类事物”这个概念是相对的，它因为粒度视图不同而不同。
例如，在我的眼里，我是一个人，和一头猪有本质区别，我可以接受我和我同学是同类这个说法，但绝不能接受我和一头猪是同类。但是，如果在一个动物学家眼里，我和猪应该是同类，因为我们都是动物，他可以认为“人”和“猪”都实现了IAnimal这个接口，而他在研究动物行为时，不会把我和猪分开对待，而会从“动物”这个较大的粒度上研究，但他会认为我和一棵树有本质区别。
现在换了一个遗传学家，情况又不同了，因为生物都能遗传，所以在他眼里，我不仅和猪没区别，和一只蚊子、一个细菌、一颗树、一个蘑菇乃至一个SARS病毒都没什么区别，因为他会认为我们都实现了IDescendable这个接口（注：descend vi. 遗传），即我们都是可遗传的东西，他不会分别研究我们，而会将所有生物作为同类进行研究，在他眼里没有人和病毒之分，只有可遗传的物质和不可遗传的物质。但至少，我和一块石头还是有区别的。
可不幸的事情发生了，某日，地球上出现了一位伟大的人，他叫列宁，他在熟读马克思、恩格斯的辩证唯物主义思想巨著后，颇有心得，于是他下了一个著名的定义：所谓物质，就是能被意识所反映的客观实在。至此，我和一块石头、一丝空气、一条成语和传输手机信号的电磁场已经没什么区别了，因为在列宁的眼里，我们都是可以被意识所反映的客观实在。如果列宁是一名程序员，他会这么说：所谓物质，就是所有同时实现了“IReflectabe”和“IEsse”两个接口的类所生成的实例。（注：reflect v. 反映 esse n. 客观实在）
也许你会觉得我上面的例子像在瞎掰，但是，这正是接口得以存在的意义。面向对象思想和核心之一叫做多态性，什么叫多态性？说白了就是在某个粒度视图层面上对同类事物不加区别的对待而统一处理。而之所以敢这样做，就是因为有接口的存在。像那个遗传学家，他明白所有生物都实现了IDescendable接口，那只要是生物，一定有Descend（）这个方法，于是他就可以统一研究，而不至于分别研究每一种生物而最终累死。
可能这里还不能给你一个关于接口本质和作用的直观印象。那么在后文的例子和对几个设计模式的解析中，你将会更直观体验到接口的内涵。
3.面向接口编程综述
通过上文，我想大家对接口和接口的思想内涵有了一个了解，那么什么是面向接口编程呢？我个人的定义是：在系统分析和架构中，分清层次和依赖关系，每个层次不是直接向其上层提供服务（即不是直接实例化在上层中），而是通过定义一组接口，仅向上层暴露其接口功能，上层对于下层仅仅是接口依赖，而不依赖具体类。
这样做的好处是显而易见的，首先对系统灵活性大有好处。当下层需要改变时，只要接口及接口功能不变，则上层不用做任何修改。甚至可以在不改动上层代码时将下层整个替换掉，就像我们将一个WD的60G硬盘换成一个希捷的160G的硬盘，计算机其他地方不用做任何改动，而是把原硬盘拔下来、新硬盘插上就行了，因为计算机其他部分不依赖具体硬盘，而只依赖一个IDE接口，只要硬盘实现了这个接口，就可以替换上去。从这里看，程序中的接口和现实中的接口极为相似，所以我一直认为，接口（interface）这个词用的真是神似！
使用接口的另一个好处就是不同部件或层次的开发人员可以并行开工，就像造硬盘的不用等造CPU的，也不用等造显示器的，只要接口一致，设计合理，完全可以并行进行开发，从而提高效率。
本篇文章先到这里。最后我想再啰嗦一句：面向对象的精髓是模拟现实，这也可以说是我这篇文章的灵魂。所以，多从现实中思考面向对象的东西，对提高系统分析设计能力大有脾益。
下篇文章，我将用一个实例来展示接口编程的基本方法。
而第三篇，我将解析经典设计模式中的一些面向接口编程思想，并解析一下.NET分层架构中的面向接口思想。
对本文的补充：
仔细看了各位的回复，非常高兴能和大家一起讨论技术问题。感谢给出肯定的朋友，也要感谢提出意见和质疑的朋友，这促使我更深入思考一些东西，希望能借此进步。在这里我想补充一些东西，以讨论一些回复中比较集中的问题。
1.关于“面向接口编程”中的“接口”与具体面向对象语言中“接口”两个词
看到有朋友提出“面向接口编程”中的“接口”二字应该比单纯编程语言中的interface范围更大。我经过思考，觉得很有道理。这里我写的确实不太合理。我想，面向对象语言中的“接口”是指具体的一种代码结构，例如C#中用interface关键字定义的接口。而“面向接口编程”中的“接口”可以说是一种从软件架构的角度、从一个更抽象的层面上指那种用于隐藏具体底层类和实现多态性的结构部件。从这个意义上说，如果定义一个抽象类，并且目的是为了实现多态，那么我认为把这个抽象类也称为“接口”是合理的。但是用抽象类实现多态合理不合理？在下面第二条讨论。
概括来说，我觉得两个“接口”的概念既相互区别又相互联系。“面向接口编程”中的接口是一种思想层面的用于实现多态性、提高软件灵活性和可维护性的架构部件，而具体语言中的“接口”是将这种思想中的部件具体实施到代码里的手段。
2.关于抽象类与接口
看到回复中这是讨论的比较激烈的一个问题。很抱歉我考虑不周没有在文章中讨论这个问题。我个人对这个问题的理解如下：
如果单从具体代码来看，对这两个概念很容易模糊，甚至觉得接口就是多余的，因为单从具体功能来看，除多重继承外（C#，Java中），抽象类似乎完全能取代接口。但是，难道接口的存在是为了实现多重继承？当然不是。我认为，抽象类和接口的区别在于使用动机。使用抽象类是为了代码的复用，而使用接口的动机是为了实现多态性。所以，如果你在为某个地方该使用接口还是抽象类而犹豫不决时，那么可以想想你的动机是什么。
看到有朋友对IPerson这个接口的质疑，我个人的理解是，IPerson这个接口该不该定义，关键看具体应用中是怎么个情况。如果我们的项目中有Women和Man，都继承Person，而且Women和Man绝大多数方法都相同，只有一个方法DoSomethingInWC（）不同（例子比较粗俗，各位见谅），那么当然定义一个AbstractPerson抽象类比较合理，因为它可以把其他所有方法都包含进去，子类只定义DoSomethingInWC（），大大减少了重复代码量。
但是，如果我们程序中的Women和Man两个类基本没有共同代码，而且有一个PersonHandle类需要实例化他们，并且不希望知道他们是男是女，而只需把他们当作人看待，并实现多态，那么定义成接口就有必要了。
总而言之，接口与抽象类的区别主要在于使用的动机，而不在于其本身。而一个东西该定义成抽象类还是接口，要根据具体环境的上下文决定。
再者，我认为接口和抽象类的另一个区别在于，抽象类和它的子类之间应该是一般和特殊的关系，而接口仅仅是它的子类应该实现的一组规则。（当然，有时也可能存在一般与特殊的关系，但我们使用接口的目的不在这里）如，交通工具定义成抽象类，汽车、飞机、轮船定义成子类，是可以接受的，因为汽车、飞机、轮船都是一种特殊的交通工具。再譬如Icomparable接口，它只是说，实现这个接口的类必须要可以进行比较，这是一条规则。如果Car这个类实现了Icomparable，只是说，我们的Car中有一个方法可以对两个Car的实例进行比较，可能是比哪辆车更贵，也可能比哪辆车更大，这都无所谓，但我们不能说“汽车是一种特殊的可以比较”，这在文法上都不通。
———————————————————————————————————————————————————————————————————————————
接口的起源
计算机出现以后，科学家相继开发了多种语言，从smalltalk，Pascal，Basic，C语言，C++，java,.net等等，这些语言的发展步伐，可以看作是从面向过程向面向对象发展的一段历史。很多面向对象的书在介绍自己的历史的时候，都会给读者介绍这一段历史，并鼓吹OO编程是多么多么的优异。问题是，很多刚开始学程序的人根本不知道为什么要有这个转变，他们也很难理解OO语言中的虚函数，接口等概念到底为了什么而提出来。
我们在了解这一段历史以前，首先给大家介绍一个概念——“粒度”，什么是粒度？作者认为所谓粒度其实就是一个程序中使用代码单元的组合尺度，我们可以举一个例子，沙砾——砖块——房屋模板，我们设想去修建一座房子，其实有很多中修筑方法，如果你不闲麻烦，可以使用沙砾一点点地建筑，或者将沙砾烧制为砖块，用砖块来砌，甚至直接从工厂购买房屋的门，窗，墙组件来堆砌。这三种不同的方法代表了三种不同的组合尺度。沙砾是最小的单位，使用它搭建小的房子说不定还可以，但是毫无疑问，我们必须使用很多很多“沙砾”，不便于管理；砖块比沙砾聚合了一层，可以用来修建较大的房子了；房屋模板是最高的尺寸，使用它可以快速地搭建大规模的房屋。这三种尺度的区别和联系，与我们编写程序概念是有很大的相似之处的。
在早期学习Pascal，老师告诉我们这种面向过程语言的最基本的单元是过程和函数，它们是程序中的最小的组件。过程和函数可以实现最基本的代码重用，当我们把某些固定功能的代码使用过程和函数编写后，我们可以在程序中调用它们而不必在任何需要的地方都写上这样一段代码，这样的好处是显而易见的。在一些小型的程序里面，使用过程和函数是合适的，但是在大中型程序中，它们的弊端就显示出来，过程和函数的粒度太低了，如果我们一个系统，有10000个函数和过程，我们的程序员将不得不花费大量的时间去寻找和维护它们，10000个没有任何关系的函数和过程的管理难度是显而易见的，就好像10000个人的企业一样，如果没有部门和职务，这还不乱了套？！
面向对象语言的出现，就是为了解决这个问题，别听OO语言吹的天花乱坠，其实它出现就为一个理由——提高编程的粒度。面向对象语言的基本单位是类 CLASS，类封装了很多数据成员和成员函数，过程，将最小组件的提高了一个等级，我们需要直接操作的不是过程和函数了，而是一个个更高层次上的类。我们把10000人分了很多部门，不同的部门负责不同的事宜，这样公司终于可以走上正轨了。
做成了类CLASS是否就万事大吉了呢？不一定，新的问题随之而来，也许我们有一个部门的人很多，可以做很多事情，如何在部门内部实现更好的管理呢？好比我们有一个类，它提供了很多种方法和属性，这些方法和属性其实可以分为一堆堆，为不同的功能服务，但是我们的类并没有做这个管理。在AO种，map对象拥有很多功能，比如管理图层，管理元素，管理选择集，进行地图显示，每种不同的功能都有好多方法和属性，现在这些属性和方法是杂乱无章，没有任何区别堆积在一个类里面的，当我们的程序员需要寻找一个方法的时候，不得不一个个去寻找，很不方便。
这个时候，接口interface出现了，C++的发明者第一次提出纯虚函数（其实就是接口）概念的时候，遭到了很多抵制，很多人都不明白接口的意义何在，我们用虚函数好好的，何必又出来个啥东西都没有的空架子？说它是类吧，又不能实现产生一个对象；说它是对象吧，又没有方法体来使用。接口出来干了一件好事，就是将类内部进行分类。对于map对象，我们可以做好几个接口，这些接口中定义不同功能的方法，函数和属性，map类实现这些接口，这样我们可以使用接口定义，实现对象。因此，所谓接口就是一系列相关方法与属性集合的定义。
好了，我们罗嗦了这么多，已经走进了COM的概念了，在正式介绍COM以前我们得最后罗嗦一点：计算机语言的发展历史，其实就是一部不断提高组件粒度的历史，不断提高代码重用的历史。以前我们使用过程和函数，后来我们使用类，现在我们使用接口，都是为了一个目的，让我们操作的组件在具体和抽象之间寻找一个平衡点。太具体了，如过程和函数，就没有了框架；太抽象，如类，就无法分别。
一个代码示例：
==============================================================================
选择Java接口还是抽象类
很多人有过这样的疑问：为什么有的地方必须使用接口而不是抽象类，而在另一些地方，又必须使用抽象类而不是接口呢？或者说，在考虑Java类的一般化问题时，很多人会在接口和抽象类之间犹豫不决，甚至随便选择一种。
实际上接口和抽象类的选择不是随心所欲的。要理解接口和抽象类的选择原则，有两个概念很重要：对象的行为和对象的实现。如果一个实体可以有多种实现方式，则在设计实体行为的描述方式时，应当达到这样一个目标：在使用实体的时候，无需详细了解实体行为的实现方式。也就是说，要把对象的行为和对象的实现分离开来。既然Java的接口和抽象类都可以定义不提供具体实现的方法，在分离对象的行为和对象的实现时，到底应该使用接口还是使用抽象类呢？
通过抽象类建立行为模型
在接口和抽象类的选择上，必须遵守这样一个原则：行为模型应该总是通过接口而不是抽象类定义。为了说明其原因，下面试着通过抽象类建立行为模型，看看会出现什么问题。
假设要为销售部门设计一个软件，这个软件包含一个“发动机”（Motor）实体。显然无法在发动机对象中详细地描述发动机的方方面面，只能描述某些对当前软件来说重要的特征。至于发动机的哪些特征是重要的，则要与用户（销售部门）交流才能确定。
销售部门的人要求每一个发动机都有一个称为马力的参数。对于他们来说，这是惟一值得关心的参数。基于这一判断，可以把发动机的行为定义为以下行为。
行为1：查询发动机的马力，发动机将返回一个表示马力的整数。
虽然现在还不清楚发动机如何取得马力这个参数，但可以肯定发动机一定支持这个行为，而且这是所有发动机惟一值得关注的行为特征。这个行为特征既可以用接口定义，也可以用抽象类定义。为了说明用抽象类定义可能出现的问题，下面用抽象类建立发动机的行为模型，并用Java方法描述行为1，代码如下：
代码
在Motor抽象类的基础上构造出多种具体实现，例如A型发动机、B型发动机等，再加上系统的其它部分，最后得到1.0版的软件并交付使用。一段时间过去了，现在要设计2.0版的软件。在评估2.0版软件需求的过程中，发现一小部分发动机是电池驱动的，而电池需要一定的充电时间。销售部门的人希望能够通过计算机查阅充电时间。根据这一要求定义一个新的行为，如图1所示。
行为2：查询电驱动发动机的充电时间，发动机将返回一个表示充电时间的整数。
用Java方法来描述这个行为，代码如下：
代码
在销售部门的软件中，电驱动发动机也以类的形式实现，但这些类从BatteryPoweredMotor而不是Motor派生。这些改动加入到2.0版软件之后，销售部门很满意。随着业务的不断发展，不久之后光驱动的发动机出现了。销售部门要求光驱动发动机需要一定光能才能运转，光能以流明（Lumen）度量。这个信息对客户很重要，因为下雨或多云的天气里，某些光驱动发动机可能无法运转。销售部门要求为软件增加对光驱动发动机的支持，所以要定义一个新的行为。
行为3：查询光驱动发动机能够正常运转所需要的最小流明数，发动机返回一个整数。
再定义一个抽象类并把行为3转换成Java方法，代码如下：
代码
如图1所示，SolarPoweredMotor和BatteryPoweredMotor都从Motor抽象类派生。在整个软件中，90%以上的代码以相同的方式对待所有的发动机。偶尔需要检查一下发动机是光驱动还是电驱动，使用instanceof实现，代码如下：
代码
无论是哪种发动机，马力这个参数都很重要，所以在所有派生的抽象类（SolarPoweredMotor和BatteryPoweredMotor）中，getHorsepower()方法都有效。
现在销售部门又有了一种新的发动机，它是一种既有电驱动又有光驱动的双重驱动发动机。光驱动和电驱动的行为本身没有变化，但新的发动机同时支持两种行为。在考虑如何定义新型的光电驱动发动机时，接口和抽象类的差别开始显示出来了。新的目标是在增加新型发动机的前提下尽量少改动代码。因为与光驱动发动机、电驱动发动机有关的代码已经过全面的测试，不存在已知的Bug。为了增加光电驱动发动机，要定义一个新的SolarBatteryPowered抽象类。如果让SolarBatteryPowered从Motor抽象类派生，SolarBatteryPowered将不支持针对光驱动发动机和电驱动发动机的instanceof操作。也就是说，如果查询一个光电驱动的发动机是光驱动的，还是电驱动的，得到的答案是：都不是。
如果让SolarBatteryPowered从SolarPoweredMotor（或BatteryPoweredMotor）抽象类派生，类似的问题也会出现，SolarBatteryPowered将不支持针对BatteryPoweredMotor（或SolarPoweredMotor）的instanceof操作。从行为上看，光电驱动的发动机必须同时从两个抽象类派生，但Java语言不允许多重继承。之所以会出现这个问题，根本的原因在于使用抽象类不仅意味着定义特定的行为，而且意味着定义实现的模式。也就是说，应该定义一个发动机如何获得行为的模型，而不仅仅是声明发动机具有某一个行为。
通过接口建立行为模型
如果用接口来建立行为模型，就可以避免隐含地规定实现模式。例如，前面的几个行为改用接口定义如下。
行为1：
代码
行为2：
代码
行为3：
代码
现在光电驱动的发动机可以描述为：
代码
public DualPoweredMotor implements SolarPoweredMotor, BatteryPoweredMotor{}
DualPoweredMotor只继承行为定义，而不是行为的实现模式，如图2所示。
在使用接口的同时仍旧可以使用抽象类，不过这时抽象类的作用是实现行为，而不是定义行为。只要实现行为的类遵从接口定义，即使它改变了父抽象类，也不用改变其它代码与之交互的方式。特别是对于公用的实现代码，抽象类有它的优点。抽象类能够保证实现的层次关系，避免代码重复。然而，即使在使用抽象类的场合，也不要忽视通过接口定义行为模型的原则。从实践的角度来看，如果依赖于抽象类来定义行为，往往导致过于复杂的继承关系，而通过接口定义行为能够更有效地分离行为与实现，为代码的维护和修改带来方便。
==============================================================================
Java接口特性
在Java中看到接口，第一个想到的可能就是C++中的多重继承和Java中的另外一个关键字abstract。从另外一个角度实现多重继承是接口的功能之一，接口的存在可以使Java中的对象可以向上转型为多个基类型，并且和抽象类一样可以防止他人创建该类的对象，因为接口不允许创建对象。
interface关键字用来声明一个接口，它可以产生一个完全抽象的类，并且不提供任何具体实现。interface的特性整理如下：
1. 接口中的方法可以有参数列表和返回类型，但不能有任何方法体。
2. 接口中可以包含字段，但是会被隐式的声明为static和final。
3. 接口中的字段只是被存储在该接口的静态存储区域内，而不属于该接口。
4. 接口中的方法可以被声明为public或不声明，但结果都会按照public类型处理。
5. 当实现一个接口时，需要将被定义的方法声明为public类型的，否则为默认访问类型，Java编译器不允许这种情况。
6. 如果没有实现接口中所有方法，那么创建的仍然是一个接口。
7. 扩展一个接口来生成新的接口应使用关键字extends，实现一个接口使用implements。
interface在某些地方和abstract有相似的地方，但是采用哪种方式来声明类主要参照以下两点：
1. 如果要创建不带任何方法定义和成员变量的基类，那么就应该选择接口而不是抽象类。
2. 如果知道某个类应该是基类，那么第一个选择的应该是让它成为一个接口，只有在必须要有方法定义和成员变量的时候，才应该选择抽象类。因为抽象类中允许存在一个或多个被具体实现的方法，只要方法没有被全部实现该类就仍是抽象类。
以上就是接口的基本特性和应用的领域，但是接口绝不仅仅如此，在Java语法结构中，接口可以被嵌套，既可以被某个类嵌套，也可以被接口嵌套。这在实际开发中可能应用的不多，但也是它的特性之一。需要注意的是，在实现某个接口时，并不需要实现嵌套在其内部的任何接口，而且，private接口不能在定义它的类之外被实现。
标签：ret 相关 其它 关注 动物 coupling 显示 orm 没有
原文地址：https://www.cnblogs.com/feng9exe/p/9936848.html
