Put it in the program and say it. If a class cannot determine its final type, that is, it does not know how it will be implemented in the future, interface-oriented programming can be used. All the places that need this class are set as an interface, and let this class inherit this interface. When you want to change it later, you just need to inherit this interface. -------------------------------------------------- -------------------------------------------------- -------------------------------
There is one point in object-oriented design that everyone has basically reached a consensus on, that is, interface-oriented programming. I think most people have no doubts about this.The question is how do we reflect it in actual project development? Is it just that every implementation provides an interface? Conversely, do you sometimes feel that interfaces are superfluous? Or, you just think that frameworks like spring are used to using interfaces this way and take it for granted.
Design pattern analysis mentioned several perspectives of object-oriented design considerations, one is the conceptual layer, the other is the specification layer, and the other is the implementation layer. If I'm not wrong, most of us actually keep our eyes on the implementation layer, which is what object-oriented design tries to avoid, i.e. you don't focus on these details at the beginning, you focus on is the protocol (interface).
For actual project development, if we divide the implementation process into multiple stages, we might as well divide it like this. In the first stage, we design our interface according to the needs of the client side. At this stage, there is no implementation, all The task is to define the responsibilities required by the interface, as well as some po, vo required; the second stage is to implement the previously defined stipulation.
How did I do it before? I do it by cross, that is, I pretend to define an interface (actually, I am thinking that this thing is useful) , then define a method, and then immediately implement this method, and then I define another method, Continue to implement, I finally figured it out now, it's tiring, inefficient, and most importantly, it's not a real design.
How do I do it now? For example, in a list.jsp , you need to query, list, and then look at the detailed information, and then add information. I will define it in the interface in the first step ( this process will have a sense of overall design ), and I don't care about the underlying implementation ( database, transaction) ) , my goal is " I want this function, I want that function " , as for how to implement that function in the first stage, I don't think it's my business ( although this matter is still up to me in the end ). Let 's see What is the essential difference between this process and the previous process? That is, the concept of layering is more obvious, your work is more layered, and each time there are steps to design and then implement, and the previous process can easily make you fall into the trap of pure implementation unknowingly. -------------------------------------------------- -------------------------------------------------- -------------------------------
What is Interface Oriented Programming?
In an object-oriented system, the various functions of the system are completed by the cooperation of many different objects. In this case, how each object implements itself is not so important to the system designer; and the cooperative relationship between each object becomes the key to system design. From the communication between different classes to the interaction between the modules, it is important to consider at the beginning of the system design, which is also the main work content of the system design. I think interface-oriented programming refers to programming according to this idea! In fact, in your daily work, you have already programmed according to the interface, but if you do not have this awareness, then you are just passively implementing this idea; it is manifested in frequent complaints that the code changed by others affects you (the interface Not designed), manifested in the large-scale adjustment of other modules caused by changes in a module (module interface is not well designed) and so on.
When Mr. Booch talked about Interaction Designer that day , he meant people who did this kind of design, but at a higher level. I think this type of person is one of the most lacking talents in our software design team. Non-interface programming? Is it the process-oriented programming idea?
1. Understanding of the interface.
From a deeper understanding of the interface, it should be the separation of definition (norm, constraint) and implementation (principle of separation of name and reality).
When we generally implement a system, we usually integrate the definition and implementation into one without separation. I think the most understood system design specification should be the separation of all definitions and implementations, although this may affect some parts of the system. The situation is a bit complicated.
The interface itself reflects the system designer's abstract understanding of the system.
There should be two types of interfaces:
The first category is an abstraction of an entity, which can correspond to an abstract class ;
The second category is the abstraction of a certain aspect of an entity, that is, an abstract surface ( interface );
An entity may have multiple abstract faces.
There is a difference between an abstract body and an abstract surface.
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编程，原意是指面向抽象协议编程，实现者在实现时要严格按协议来办。也就是BillJoy同志说的，一边翻rfc，一边写代码的意思。面向对象编程是指面向抽象和具象。抽象和具象是矛盾的统一体，不可能只有抽象没有具象。一般懂得抽象的人都明白这个道理。但有的人只知具象却不知抽象为何物。
所以只有interface没有实现，或只有实现而没有interface者是没有用的，反OO的。
所以还是老老实实面向对象编程，面向协议编程，或者什么都不面向，老老实实编程。
但是我很讨厌讨论这样的术语，不如我们谈谈什么叫面向领导的编程？面向用户的编程？领导和用户有时都很BT，我们就面向BT编程？
选择Java接口还是抽象类
很多人有过这样的疑问：为什么有的地方必须使用接口而不是抽象类，而在另一些地方，又必须使用抽象类而不是接口呢？或者说，在考虑Java类的一般化问题时，很多人会在接口和抽象类之间犹豫不决，甚至随便选择一种。
实际上接口和抽象类的选择不是随心所欲的。要理解接口和抽象类的选择原则，有两个概念很重要：对象的行为和对象的实现。如果一个实体可以有多种实现方式，则在设计实体行为的描述方式时，应当达到这样一个目标：在使用实体的时候，无需详细了解实体行为的实现方式。也就是说，要把对象的行为和对象的实现分离开来。既然Java的接口和抽象类都可以定义不提供具体实现的方法，在分离对象的行为和对象的实现时，到底应该使用接口还是使用抽象类呢？
通过抽象类建立行为模型
在接口和抽象类的选择上，必须遵守这样一个原则：行为模型应该总是通过接口而不是抽象类定义。为了说明其原因，下面试着通过抽象类建立行为模型，看看会出现什么问题。
假设要为销售部门设计一个软件，这个软件包含一个“发动机”（Motor）实体。显然无法在发动机对象中详细地描述发动机的方方面面，只能描述某些对当前软件来说重要的特征。至于发动机的哪些特征是重要的，则要与用户（销售部门）交流才能确定。
销售部门的人要求每一个发动机都有一个称为马力的参数。对于他们来说，这是惟一值得关心的参数。基于这一判断，可以把发动机的行为定义为以下行为。
行为1：查询发动机的马力，发动机将返回一个表示马力的整数。
虽然现在还不清楚发动机如何取得马力这个参数，但可以肯定发动机一定支持这个行为，而且这是所有发动机惟一值得关注的行为特征。这个行为特征既可以用接口定义，也可以用抽象类定义。为了说明用抽象类定义可能出现的问题，下面用抽象类建立发动机的行为模型，并用Java方法描述行为1，代码如下：
代码
public abstract Motor{
abstract public int getHorsepower();
}
在Motor抽象类的基础上构造出多种具体实现，例如A型发动机、B型发动机等，再加上系统的其它部分，最后得到1.0版的软件并交付使用。一段时间过去了，现在要设计2.0版的软件。在评估2.0版软件需求的过程中，发现一小部分发动机是电池驱动的，而电池需要一定的充电时间。销售部门的人希望能够通过计算机查阅充电时间。根据这一要求定义一个新的行为，如图1所示。
行为2：查询电驱动发动机的充电时间，发动机将返回一个表示充电时间的整数。
用Java方法来描述这个行为，代码如下：
代码
public abstract BatteryPoweredMotor extends Motor{
abstract public int getTimeToRecharge();
}
在销售部门的软件中，电驱动发动机也以类的形式实现，但这些类从BatteryPoweredMotor而不是Motor派生。这些改动加入到2.0版软件之后，销售部门很满意。随着业务的不断发展，不久之后光驱动的发动机出现了。销售部门要求光驱动发动机需要一定光能才能运转，光能以流明（Lumen）度量。这个信息对客户很重要，因为下雨或多云的天气里，某些光驱动发动机可能无法运转。销售部门要求为软件增加对光驱动发动机的支持，所以要定义一个新的行为。
行为3：查询光驱动发动机能够正常运转所需要的最小流明数，发动机返回一个整数。
再定义一个抽象类并把行为3转换成Java方法，代码如下：
代码
public abstract SolarPoweredMotor extends Motor{
abstract public int getLumensToOperate();
}
如图1所示，SolarPoweredMotor和BatteryPoweredMotor都从Motor抽象类派生。在整个软件中，90％以上的代码以相同的方式对待所有的发动机。偶尔需要检查一下发动机是光驱动还是电驱动，使用instanceof实现，代码如下：
代码
if (instanceof SolarPoweredMotor){...}
if (instanceof BatteryPoweredMotor){...}
无论是哪种发动机，马力这个参数都很重要，所以在所有派生的抽象类（SolarPoweredMotor和BatteryPoweredMotor）中，getHorsepower()方法都有效。
现在销售部门又有了一种新的发动机，它是一种既有电驱动又有光驱动的双重驱动发动机。光驱动和电驱动的行为本身没有变化，但新的发动机同时支持两种行为。在考虑如何定义新型的光电驱动发动机时，接口和抽象类的差别开始显示出来了。新的目标是在增加新型发动机的前提下尽量少改动代码。因为与光驱动发动机、电驱动发动机有关的代码已经过全面的测试，不存在已知的Bug。为了增加光电驱动发动机，要定义一个新的SolarBatteryPowered抽象类。如果让SolarBatteryPowered从Motor抽象类派生，SolarBatteryPowered将不支持针对光驱动发动机和电驱动发动机的instanceof操作。也就是说，如果查询一个光电驱动的发动机是光驱动的，还是电驱动的，得到的答案是：都不是。
如果让SolarBatteryPowered从SolarPoweredMotor（或BatteryPoweredMotor）抽象类派生，类似的问题也会出现，SolarBatteryPowered将不支持针对BatteryPoweredMotor（或SolarPoweredMotor）的instanceof操作。从行为上看，光电驱动的发动机必须同时从两个抽象类派生，但Java语言不允许多重继承。之所以会出现这个问题，根本的原因在于使用抽象类不仅意味着定义特定的行为，而且意味着定义实现的模式。也就是说，应该定义一个发动机如何获得行为的模型，而不仅仅是声明发动机具有某一个行为。
通过接口建立行为模型
如果用接口来建立行为模型，就可以避免隐含地规定实现模式。例如，前面的几个行为改用接口定义如下。
行为1：
代码
public interface Motor(){
public int getHorsepower();
}
行为2：
代码
public interface BatteryPoweredMotor extends Motor(){
public int getTimeToRecharge();
}
行为3：
代码
public interface SolarPoweredMotor extends Motor{
abstract public int getLumensToOperate();
}
现在光电驱动的发动机可以描述为：
代码
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接口不能在定义它的类之外被实现。
First of all, it is necessary to understand what an interface is. The interface is the standard. There are many interfaces in life. Such as faucet water pipe interface, power interface and so on. There are many faucet manufacturers now. Before adopting the interface, the manufacturer must provide the faucet and the downpipe at the same time. They are integrated and cannot be changed. At the same time, it only applies to this one of his products. With the interface, the manufacturer does not need to worry about the design of its sewer pipe, and only uses the interface standard to produce the faucet, and after completion, it can be directly connected to the sewer pipe. This is interface-oriented. This way, your downpipe can use all the faucets that meet the standards of the downpipe, instead of the previous one. And it is more convenient to replace the faucet.