Code for interface and the type erasure problem

Question

As a design priciple I was taught:

Programe para una interfaz, no para una implementación. Es decir, no se deben declarar las variables con el tipo de los herederos sino con el tipo de los supertipos.

Translated:

Code for an interface, not for an implementation. That is to say, variables should not be declared with the type of the subtypes but with the type of the supertypes.

But that easily runs into problems of type slicing when I actually have to obtain the type of the subclass to perform specific operations.

How is the problem of type erasure normally solved in reality?

Answer 1

Code for an interface, not for an implementation. That is to say, variables should not be declared with the type of the subtypes but with the type of the supertypes.

But that easily runs into problems of type slicing when I actually have to obtain the type of the subclass to perform specific operations.

How is the problem of type erasure normally solved in reality?

(Understood "type erasure" in this context, but actually it is used in Java for generic type parameters as used in collections.)

Apparently the subject is having a collection, say a list of an interface.

The principle interface over class has several well founded reasons. For the reader still not familiar with those, read about them, they improve expressive coding enormously.

1 All items the same class

The case where all list items are actually of the same class means that the interface is not complete. Again in java you can have an interface extending more than one interface. Or you can look for a more specific interface. If you have an interface Set implemented as class TreeSet but expect that the items are ordered like in TreeSet pick the interface SortedSet. The operational requirements must be satisfied by the typing. This might mean using a class instead. For a class bound to a local application there may very well be no reason to artificially split it in interface and implementing class = a wrong legalistic approach, costing time.

2 Items with very different classes

The case where all list items are actually of the different case classes which later need to be handled per case class, is painful. One may assume that the use of the specific class may not be captured in a more extended interface. That would be easy. So actually you threw together things that still needed to be kept separate. Keep the items in separate lists (too). As already mentioned for the case of lists of same class implementations they may expose the class not the interface. Keep the cutlery separate.

3 Different classes, but you must live with them

The last case concerns having to live with mixture of things, needed to be treated differently. An example (in java):

List<Animal> animals = ...
List<Swimming> swimmers = animals
    .stream()
    .filter(a -> a instanceof Swimming)
    .map(Swimming.class::cast)
    .collect(Collectors.toList())
;
List<Flying> flyers = animals
    .stream()
    .filter(a -> a instanceof Flying)
    .map(Flying.class::cast)
    .collect(Collectors.toList())
;

This case not necessarily is based on inheritance (as here with instanceof). You might have:

interface/class Animal {
    Optional<Swimming> asSwimming();
    <T> Optional<T> as(Class<T> type);
    ...

Following the single responsibility principle: then keep code for every implementation class in a separate source. There is not much more you can do about that. It happens.

Answer 2

First, if you have to

obtain the type of the subclass to perform specific operations

it is a sign that your design may be wrong. This can have different causes:

• there might be an operation missing in the interface supertype

• or - more likely - the context requires to use the subtype, and the "design principle" (which is actually not more than a recommendation, a hint) should not be applied

• or - even more likely to my experience - the whole usage of inheritance was wrong right from the start.

Of course, from time to time, you can run into situations where downcasting to a subtype is perfectly justified.

But that easily runs into problems of type slicing

This becomes only a problem when you start to copy the content of a supertype variable to another one, instead of passing references. In languages like Java, C#, Python or Perl, objects are reference types "by default", and you have to write extra code if you really want to copy an object of a supertype to another one (and so getting the risk of slicing a subtype). For example, when you create a container List<MySupertype> in C# or Java, you can test each element in that list if it has a certain subtype and then downcast.

In C++ (and maybe other languages, I don't know), however, objects usually provide copy mechanics "by default", and passing objects "by value" is far more easier than in other languages. This is sometimes beneficial, but has the drawback to make it somewhat easier to slice types accidentally. For example, by filling a std::vector<MySupertype> with different subtype objects, their original type will be erased.

Of course, in C++ the issue can be avoided similar to the former languages by using pointers, references or smart pointers - but one has to do some more extra design work here, or simply write more code. For example std::vector<MySupertype *> or std::vector<std::shared_ptr<MySupertype>> will solve the issues, but for the former you have to care about memory management and ownership, and for the latter you have to do more typing and probably more effort to resolve strange compiler error messages when you got some of the complex C++ syntax rules wrong.

Answer 3

You're overapplying the advice you've been given. For your interpretation, it might help to extend the advice further:

Code for an interface, not for an implementation. That is to say, variables should not be declared with the type of the subtypes but with the type of the supertype that correlates to the logic at hand.

For example, let's say you have a Person class, and both Student and Teacher derive from it.

If you were to write some logic that applies to all Person instances, your code should use Person (i.e. the supertype of students and teachers alike). This part you already understand.

However, the part you've glossed over is that when you're writing some logic that applies to all students (not teachers), your could should use Student. Not Person, because the code you're writing doesn't apply to all valid instanced of a Person (only students, not teachers).

Remembering what I just said, let's re-explore the problem you pointed out:

But that easily runs into problems of type slicing when I actually have to obtain the type of the subclass to perform specific operations.

If you need to perform a specific operation for which you need to know the concrete type (e.g. Student), then you shouldn't have casted your object into a Person, because you're clearly writing student logic, not person logic.

In essence, the advice you've been given doesn't apply in the problematic case you're pointing out. You should never cast to a type that is too generalized. You should only cast upwards until you reach the limit, whereby casting upwards again would lose information that you need to keep.

Answer 4

The English translation of that advice looks quite inappropriate. They are confusing "interface" and "abstract base class" most likely. Any class can implement an interface. A class can implement multiple interfaces.

For example, to handle UI objects with colours, you might have an interface that returns whether an instance is capable of having a colour, whether the colour is changeable, and a method to return the current colour and one to change the colour. Lots of totally unrelated classes can implement this interface.

So in this situation, your variables don't have any class type at all. They have an interface type. They definitely cannot have a base class type, because there is no common base class to all the classes supporting the interface which also supports the interface.

PS. There is some confusion because C++ doesn't have interfaces. Java, Objective-C, Swift and others do. And in those languages, classes and interfaces are very much unrelated.