I'd
be a little careful here. :) It all depends on whether you're using the concept
"page element" to refer to a container that locates the element on a page (that
would be composition!) or as a generalization of a content type (that would be
inheritance). It's also possible that you're mixing the two things together in
your mind.
What
i wound up doing after a lot of trial and a lot of error is to create 2 classes,
Content, and ContentContainer. In practice, Text, Image, etc all extend Content,
and Content just basically deals with ContentContainer for Text, Image, etc -
that functionality is abstracted to Content.
Sounds a little complicated, and i certainly tried to
get around that complication by trying to reduce the 2 into one class, but
it never worked. In practice, it turned out to be a lot simplier and
cleaner to use 2 classes than i would have thought. My advice, if "page
element" is meant to be a container for a type of content, that's composition.
If you wanna abstract something to a supertype, do that AFTER you get your
container working using composition. It's easy to be "deceived" with has-a /
is-a if you don't look deeply enough at the element of responsibility in an
object.
:)
nando
> I'm not sure I understand why this isn't an
"is-a" relationship. The basic component is called a PageElement, and all
of the classes that extend are PageElements. For example, an "image is
a page element" and a "text block is a page element", is this too
general of a way to use inheritance? An element must be serializable,
deserializable, and must have a display() method.
