Re: ADC Core Data article
Re: ADC Core Data article
- Subject: Re: ADC Core Data article
- From: Paul Szego <email@hidden>
- Date: Fri, 8 Apr 2005 21:50:41 +1200
On 06/04/2005, at 7:52 PM, mmalcolm crawford wrote:
On Apr 5, 2005, at 11:22 PM, Paul Szego wrote:
On 06/04/2005, at 2:48 PM, Will Mason wrote:
On the other hand, if you don't need all these services and just aim
for persistence, CoreData aren't what you need: just use an
NSArchiver, and you get the support for any NSObject :))
No, you don't. An object can be archived (sent to/read from an
NSCoder)
only if it adopts the NSCoding protocol.
A similar approach for CoreData would be better. Having a base class
that implements this for free is a good thing, as long as that's not
the only way to do it. Hopefully you wont be forced to extend a
specific base class - that's just bad design.
The article is very clear:
"By default, the class used is NSManagedObject, but the class may be
either NSManagedObject or a subclass thereof."
If Core Data only addressed object persistence, then it might be
argued that this would be poor design.
My comments were about the design of the framework, and whether it's a
persistence framework or logging framework or anything doesn't really
matter. The same principles still apply.
As noted earlier, however, it also solves a much more difficult
problem, and one that really only affects data objects. Given the
functionality that's provided for free, requiring that your model
classes inherit (ultimately) from NSManagedObject instead of NSObject
does not seem too onerous (I suspect in most cases this will simply
involve adding 7 characters to your declaration...).
Forcing someone to extend a specific base class in order to work with a
framework is fundamentally flawed, and not necessary.
You are putting serious constraints on the class hierarchy. What if
I've already got a rich class hierarchy, and only want some of my
existing classes to be persistent? What if I want my class to use two
frameworks, that both insist I extend their base class? What if I'm
already extending another base class of my own? If my object model is
one of the problem domain, I shouldn't be constrained about how to
implement it just because of a particular technology choice.
And there is no need to force such constraints onto developers. It's
bad design of the framework. It's already widely accepted to be a key
selection criteria for persistence frameworks in other development
environments, and most often solutions that force this approach on the
developer are dismissed out of hand for anything but the most trivial
of applications.
The issue here is inheritance. It shouldn't be used as a shortcut for
getting utility function for free. If we're talking about model class
(in the MVC sense) then it should be used to model "IS-A" relationships
that exist between the things these classes represent in the underlying
problem domain.
It's also so very simple to avoid. Just define a protocol for the
responsibilities of a class wanting to participate in whatever this
framework offers. You can always provide a "helper" base class for the
simple (perhaps even majority) case where that's suitable. Then if you
can't or don't want to extend the base class you're not dead in the
water.
Indeed it's reasonable to argue that putting all the functionality of
a model object into the root class would be bad design. It would add
an unnecessary overhead to all the other system classes, from views to
controls to strings (which don't need to know what entity they
represent or what context they belong to(*))...
I didn't suggest that it belongs in NSObject. I also believe that would
be a mistake.
Paul.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden