I like that you showed a simple guideline for reasoning about this problem, and I think it works great for lots of cases. However, there are cases where it is not so easy for me to see the distinction.
For instance, I would argue that the interfaces Map, List and Set from Java represents an "is-a" relationship, and not a "can-do". Other interfaces such as Cloneable and Serializable are clearly representations of "can-do" relationships (suffix "able").
I think interfaces can be used both for "is-a" and "can-do" relationships, while abstract classes can only be used for "is-a" relationships because of the semantics of inheritance.
What if we think along the line of Interfaces for contracts and Abstract classes for partial implementations? Like how the Java API have abstract classes such as AbstractMap and AbstractList for Map and List, respectivelly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Really great article, thanks!
I like that you showed a simple guideline for reasoning about this problem, and I think it works great for lots of cases. However, there are cases where it is not so easy for me to see the distinction.
For instance, I would argue that the interfaces
Map,ListandSetfrom Java represents an "is-a" relationship, and not a "can-do". Other interfaces such asCloneableandSerializableare clearly representations of "can-do" relationships (suffix "able").I think interfaces can be used both for "is-a" and "can-do" relationships, while abstract classes can only be used for "is-a" relationships because of the semantics of inheritance.
What if we think along the line of Interfaces for contracts and Abstract classes for partial implementations? Like how the Java API have abstract classes such as
AbstractMapandAbstractListfor Map and List, respectivelly.