Do I understand correctly that datatypes are considered related
if and only if they have IS-A relationship? Like in 'class B extends A, therefore A and B are related', is that correct?
Same question from another angle: although all classes derive from Object, we cannot say that such and such classes are related simply by having a common ancestor, right?
What about common functionality? Suppose, we take this merry bunch where all concrete classes derive from the abstract class OutputStream:
[img]
- OutputStreamFamily.png (17.49 KiB) Viewed 4641 times
[/img]
These classes have lots in common because we use them within one particular domain, IO operations, yet we can't say that FileOutputStream and ObjectOutputStream are related? or can we? Similarly, would having a common superinterface make classes related? Like, lots of data structures implement Collection; are LinkedHashSet, ArrayList and LinkedList related? Okay, so these particular types override many methods, but what about the case where some classes are using lots of common methods defined in a superinterface? By the way, what
IS a common method, precisely? the one that has the same signature across several classes? or just a commonly shared name?
All these questions lead to this: what reasons would make us choose interfaces over abstract classes? Right now I'm thinking that we should start our hierarchy with an interface when classes that implement it have many common – or should I say 'non-overridden'? – methods, but I keep seeing conflicting info on the web… Some people maintain that if state more important than behavior we'd better use abstract class… And then there is always this mind-boggling Java Collections Framework where AbstractCollection sits right underneath Collection, which sort of hints on practically equal importance… Frankly, I'm lost here; need a friendly nudge in right direction…