Start with Object.
I usually create my own "Model" base class for my application
(subclass of Object). I have an application right now called Epic, so
I have an EpicModel. It makes a convenient home for shared
functionality.
Don't fall into the trap of subclassing collections. You almost always
want your domain object to have a collection, not be a collection.
It has been rare in my applications to have domain models that are
subclasses of something already in the image. Honestly can't think of
it happening once (though I'm sure that it has).
The domain is one place where you can be really clean. You usually
don't have that luxury in the presentation, controller, persistence,
etc.
On Sun, Aug 17, 2008 at 6:19 PM, Andy Burnett
<
[hidden email]> wrote:
> The HPI Seaside tutorial shows the data models as subclasses of Object, and
> I have seen that elsewhere. However, some examples talk about finding the
> closest class to use as your starting point. I am curious what experienced
> Squeakers do.
>
> Subclassing Object presumably gives maximum flexibility, but perhaps means
> that one ends up building in functionality that already exists further down
> the tree. On the other hand, taking a more specific class, might be a bit
> like premature optimisation?
>
> Cheers
> AB
>
> _______________________________________________
> Beginners mailing list
>
[hidden email]
>
http://lists.squeakfoundation.org/mailman/listinfo/beginners>
>
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Locked
