Daniel asked, in his Editor's blog, "Is it still OO if we don't get to subclass?" I think it is. I don't think that inheritance is a core feature of OO programming. While it's definitely an extremely useful feature (no polymorphism without it), the absolute core feature of OO is having the code located with the data, and that feature is not lost if you lose inheritance.
On the inheritance vs. Interfaces argument, I am becomingly increasingly convinced that interfaces are of the utmost importance. With the bulk of my work over the last year being refactoring, it has been clear that, had the original authors used an interface inheritance hierarchy instead of a concrete inheritance hierarchy, my job would have been as simple as creating a new implementation of said interfaces. Instead, it has involved masses of refactoring, extracting super classes and interfaces, moving methods, changing code everywhere to not refer to concrete classes that are no longer applicable.
There are definitely some people who use inheritance WAY too liberally. It must be an "is a" relationship. A Human is a Mammal is an Animal. But a Request is not a HashMap. It may consist largely, or even solely, of a map of values, but that does not mean it IS a map. This is particularly important, because the request may evolve to become MORE than that. No matter how you Human class grows, it will always be a subclass of Mammal.
The most important thing, though, I feel, is planning. Interface and class hierarchies need to be planned, and reviewed and scrutinised, ideally at a team level. Once you have the right hierarchy, the most sensible thing you can do is to only ever program against the interfaces, even hiding the concrete classes from existence (using package or private visibility) if possible.
</twocents>
Graham. |
java.net RSS Feeds
