Re: hierarchy of interface/implementations.
horos11@gmail.com wrote:
yeah, I sort of gathered that you couldn't do this, but I think that
is more a limitation of java than anything else. You may argue not so
for interfaces, because you can have a class implement many of them
(and hence the 'inheritance' tree is really a bush), but for an
abstract class - or any arbitrary class for that matter - I think it
is a lot clearer to have an inherited class tied to its parent in a
very clear way.
The package structure of Java, namespace structure of C++, and module
structure of Python (among other analogues in other programming
languages) would tend to disagree. It is often desirable to have anyone
extend an interface: for example, java.awt.LayoutManager is a good
example of this. It is implemented more frequently in other packages
than its own java.awt.
Your idea would also work poorly if you have deeper trees. If I want a
JTable, I'd like to be able to say JTable and not
Component.Container.JTable (I'm even skipping JComponent here!). Or how
about Component.Container.Window.Dialog? Most names are already
explanatory of their inheritance: a dialog is obviously a window, a
container, and a component.
Consider the whole reader design decision in java. I personally think
that
Reader.InputStream
is a lot clearer than
InputStreamReader
because it implicitly shows the relationship between the two classes,
and lends itself to a hierarchy
(like files inside a directory belong to that directory).
I disagree. An InputStreamReader is, well, an input stream reader. A
Reader.InputStream is the input stream of a reader (as I read it,
anyways). The use of `.' tends to imply a composition element; for
example, Map.Entry is the entry of a map.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth