OK, in the case of a class implementing multiple interfaces because it has multiple roles, I agree with you.

The article seems to be saying that all classes should have separate interfaces, though. I don’t often create classes which have multiple roles, so most of my classes don’t implement separate abstractions. I prefer to use separate classes (and consequently separate interfaces, since each class has its own public interface) for separate roles, it seems simpler to me that way.

If a class has several roles, it’s public interface is a mix of methods from all these roles. The premise here is that when one of those roles change later, as the role is not explicitly defined by a separate interface, deciding what to refactor and what to leave might be a challenge. If the role is explicitly defined by an interface, then the definition is clear. (That’s my understanding)

I always thought that all classes HAVE an interface. In Java, we have four different accessibility levels (public, protected, package private/default, and private) for the members of a class.

In my understanding, the set of public members of a class C is the “public interface” of the class. So, if another class C’ in a different package uses this public interface of C, then we DO have “an interface defining the relationship between two classes”, and that relationship is very explicit.

Where is the error in this understanding?