[Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?
Rogan Creswick
creswick at gmail.com
Fri Oct 30 01:32:43 EDT 2009
On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds
<magicloud.magiclouds at gmail.com> wrote:
> My concern here is about the data member inheriting. In OOP, when I
> inherit a class, I also got the members of it. But in haskell, how to
> inherit a "data"?
In my experience (almost entirely with Java), it is usually a bad idea
to inherit from a class in order to reuse data storage that the parent
class provides. Encapsulation (or a decorator, if you prefer) is
often a safer choice. If you really do need to meet the interface
provided by the parent class, while adding functionality (*and* you
can't just implement that interface independently of extending the
parent class), then it's often possible to still use a decorator, and
provide limited visibility accessors to the encapsulated field you
need (say, to pass into some unmodifiable legacy API). When you get
down to it, it's extremely hard to design a full-fledged class so that
extending it actually makes sense, and can be done in a useful and
safe manner. Extending concrete classes also brings along some
non-trivial maintenance headaches as well, since you now need to be
aware of changes to (some of) the non-public APIs when libraries are
upgraded, etc... it's a mess. This is a large part of why the
majority of the concrete classes in the Google Collections library are
final -- the limited benefit of extensibility isn't worth the design
and maintenance.
The point of that whole rant is that extending data-bearing classes
isn't necessarily a good idea, so before trying to find a way to do it
with haskell, it may be better to just encapsulate another data type,
which is trivial:
data InnerThing = A | B | C
data OuterThing = Outer { innerThing :: InnerThing, otherField :: Int }
--Rogan
> --
> 竹密岂妨流水过
> 山高哪阻野云飞
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
More information about the Haskell-Cafe
mailing list