> You may recognize the database.Bar/database._Bar pattern as that
> generated from an eomodel by (Java)EOGenerator. _Bar isn't supposed
> to be modified. And I can't (easily) modify database.Bar because it
> is produced and maintained by others.
And this is a good illustration of the problem ... if you're extending
a class that's maintained by someone else, then you're at risk for
getting stuck here, because some day someone might hand your code an
instance of the superclass and your code is binding to a method that
the superclass doesn't have. Now if your code KNOWS that it can only
receive your custom subclass, then you should make your parameter and
return types make that knowledge explicit so the type system can
enforce it.
> Extension of base classes to add functionality is a principal
> feature of O-O design. If one had absolutely no access to the base
> class (very common), one couldn't add abstract/empty methods to the
> base class in order to extend the base class in a safe manner. So
> your solution doesn't seem like a very general one.
No, you don't have to. But it is NOT that case that Bar's superentity
provides that method, even if all of your subclasses do (unless you
add that method to the supertype or make it declare an additional
interface). What WOULD make it true is for all of your subclasses to
implement a common interface and methods that refer to that type
require/vend that particular interface. The other option is to have
all of your custom subclasses extend your own common subclass
(basically make an abstract stub entity that they extend) and declare
THAT entity to have the baz() method.
ms
This archive was generated by hypermail 2.0.0 : Fri Mar 14 2008 - 18:57:03 EDT