Re: ADC Core Data article

FROM : Paul Szego
DATE : Fri Apr 08 11:50:41 2005

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.