Programming for the interface means programming for a super type, why?

I will not go into details about concrete classes, abstract classes, interfaces, because the AP has already asked a lot of questions about this and has already received answers where it has a lot of material.

I can not guarantee if it has a formal definition that indicates what can be considered super-type or not. In my view anything that can be used as a basis for other types is a super-type. Including interface, then the statement is true.

If you will prefer a concrete, abstract or interface class, it really depends on the case and there is material on the site to help you understand generically when to use each.

The interface is the easiest type to implement. The abstract class is in the middle because it has purely abstract and concrete parts. Concrete is more complicated because you can only change the implementation through virtualization (or some mechanism that has the same effect) and this is not so simple.

The interface gives more freedom of implementation and is more restricted in what it does, so it is a way to program for super type, but is considered the best form.

But if in context the term is superclass, it seems to me that there is an abstract or concrete class.

The term "programming for interface" can not include classes, which are super-types, that have implementations, at least not in the part it refers to.

Java and C # do not allow multiple inheritance, only one class can be inherited, so it will almost certainly imply having implementations, which hampers the principle of "programming for interface". To better understand why, read the linked question below.

So, yes, it means, but that does not mean much. Knowing this specifically has no practical implication.

What else I could add about this is already in the question: Programming interface-oriented, not for implementation, why? .

  

Interface is an object orientation feature used in Java that defines actions that must be performed, but which each class can perform differently.

As an example:

We have the abstract class Veículo and the non-abstract classes Caminhao , Aviao that inherit from class Veículo . Do you agree with me that there is no way the truck can fly (not until today)? So the methods will be different, I can put in the abstract class Veículo the abastecer() method since it is common for all classes that inherit from it. However, as the truck walks, the plane flies, so these two verbs do not belong to the same object and obviously can not be put together in the superclass.

What do I do then?

I can create two interfaces, one with the name VeiculoTerrestreInterface and the other VeiculoAereoInterface , whereas, the VeiculoTerrestreInterface interface contains the andar() method, the AviaoInterface interface will have the voar() / p>

And in your classes, using the Java programming language, it will be implemented as follows:

public class Aviao extends Veiculo implements VeiculoAereoInterface{

}

public class Caminhao extends Veiculo implements VeiculoTerrestreInterface{

}

Recapping, Airplane and Truck are Vehicles and have similar actions, right? However, both have their own actions and the other may not be able to do. For this problem, two interfaces were created so that each one of them was defined specific methods, which were to fly and walk.

In the future I can also create the class Carro and implement VeiculoTerrestreInterface since it contains the andar() method.

public class Carro extends Veiculo implements VeiculoTerrestreInterface {

}

Here is an example image:

It means you can use any object that implements the interface.

Using inheritance and polymorphism, you can access, say, a cachorro class as if it were a animal . A function can use the class, only knowing that it is a animal .

But for this you need to be in the hierarchy of these classes. What if animal has a mover() function, which many objects have? If I want to access this member, I can not do this through the animal class - not to other objects. Of course I can make everything inherit from objeto , which could contain this method. If you plan this in the beginning, go it. But if that need comes later, it means moving a lot of code back and forth (and maybe breaking things down the road).

An interesting alternative is the use of interfaces. With them, not even closely related objects can share members, which can be accessed by a function that has no idea of what the object is about unless it implements the interface.

Another relevant issue is that most languages do not allow multiple inheritance (one class inheriting from several others), while allowing a class to implement any number of interfaces.