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

Asked

Viewed 579 times

11

When we program facing an interface, does it involve programming for a super-type? What is the meaning of this?

oop interface
  • 3

    Is there a quote, a context where this is being used? The question may be somewhat ambiguous depending on the conceptualization used.

  • I came across this quote on a slide presented during my Software Engineering class, where I was without presenting an example of software that used the Strategy Project Standard, I will see if I can get this excerpt.

  • The example that raised this question is in the example found in this link: http://www2.ic.uff.br/~Anselmo/cursos/TPA/presentations_padraostrategy.pdf

  • 1

    I didn’t find this quote but I’ll try to answer.

  • The quote is not on that link, the quote is on my teacher’s slide, but I didn’t get it. But the example that triggered this issue is the same that is on the link.

  • 1

    @bigown, on this question everything is already ok. I realized the acceptance of the question.

Show 1 more comment

3 answers

8


I won’t go into details about concrete classes, abstract, interfaces, because the AP has already asked several questions about this and has already received answers where there is a lot of material.

I can’t guarantee if you have a formal definition that indicates what might be considered a super-type or not. In my view anything that can be used as a basis for other types is a super-type. Including interface, so 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 using each one.

The interface is the easiest super-type to implement. A abstract class stands in the middle because it has purely abstract and concrete parts. The concrete one is more complicated because it can only swap the implementation for virtualization (or some mechanism that gets the same effect) and this is not something so simple.

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

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

The term "interface programming" cannot include classes, which are super-types, which have implementations, at least not in the part that 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 makes the "interface programming" principle difficult. To better understand why, read the question linked down below.

So, as Ronnie Von would say, yes, it does, but that doesn’t mean much. Knowing this specifically has no practical implication.

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

  • I didn’t understand something @bigown, what you meant by the term "virtualization implementation"?

  • 1

    Use a virtual method where you can replace it with another one in the daughter class. If everything is virtual, you can say that the concrete class can function as if it were an interface. Making a design like this is probably a mistake, but theoretically it would meet the principle of "programming for interface".

  • I am not sure either, but from what I understand 'super type' is the idea of a type that can be instantiated without the object 'being' of this type. With inheritance, dog is an animal, but an object that implements an interface IInterface nay is IInterface

  • @Rsinohara you’re right in this, but I don’t know if the interface cannot be considered a super-type. I believe so, after all it can be used in place of the sub-type. I’m not very academic, so I won’t state anything, but unless someone shows me a flaw in this logic, I’ll consider the interface a super-type.

4

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

As an example:

We have the abstract class Veículo and the non-abstractive classes Caminhao, Aviao who inherit from the class Veículo. Do you agree with me that there is no way to fly the walkway (Not until today)? Therefore, the methods will be different, I can put in the abstract class Veículo the method abastecer() since it is common to all classes that inherit from it. However, while the truck is moving, the plane flies, so these two verbs do not belong to the same object and obviously cannot 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, while, the interface VeiculoTerrestreInterface contains the method andar(), the interface AviaoInterface will have the method voar().

And in its 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{

}

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

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

public class Carro extends Veiculo implements VeiculoTerrestreInterface {

}

Follow a screenshot of the example:

Classes implementando interfaces

  • 1

    I don’t really like this example because it, which is very used, uses OOP the wrong way. It uses OOP wanting to reproduce concrete things that the real world does, but the program is abstract. So doing GUI, OOP games is very useful, but when we try to play concrete things we start having problems. Now, the plane and the truck move. So they do the same thing. Only the implementation is different. I’m not saying this is wrong, but you’re being naive. So if one flies and the other walks, can be a detail that matters little publicly. which is the purpose of the interface.

  • 2

    Related: It is wrong to use class inheritance to group common behaviors and attributes?

  • Thanks for the comments, I will check the contents of the link

3

Means you can use any object that implements the interface.

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

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

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

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

Browser other questions tagged oop interface

You are not signed in. Login or sign up in order to post.