Re: ADC Core Data article

FROM : ?????Andre?
DATE : Wed Apr 06 09:55:18 2005

I think there are two reasons that they use a specific base-class.

１。Being that they wanna prevent you from core-data-izing a view 
object; short circuiting M-V-C.
２。By makeing a specific base-class that conforms to a specific 
spec, one very important feature is gained IMO: predictability.
        If any object could be stuffed in the persistent store (even 
with a protocol), then we might end up with all kinds of weird 
proprietary formats, but
        letting coredata take care of all that, it allows the format 
to be seamless, only requiring schema to instantiate other saved files
        perfectly. Anyways, out of that predictability then comes 
stability. I would rather have a framework that did something
        extremely well and 99.99% perfectly than one that had to 
account for all kinds of customizations and become a "use at your own 
risk".
        With core-data they can extrapolate the object-graph into 
whatever file type/database they see fit, and maintain 
interoperability; what happens
        if say one day apple added the compound document format, or 
something else, its all automatic we don't need to do anything.
        Its also possible that the interaction between it and the 
ObjectContext is very complex, so throwing your own class may be just 
throwing a wrench.

        I'm probably not communicating perfectly what I wanna say, 
but.... JMO.

On 平成 17/04/05, at 23:22, Paul Szego wrote:

> Many other frameworks face the same problem - and there's usually 
> two approaches. The first, and most restrictive, is to force you to 
> extend a specific base class with a bunch of behaviour built in. 
> Another is to define the responsibilities of a class that wants to 
> "play ball" (e.g. in Java via an interface, in ObjC via a protocol) 
> and let it decide how to best achieve those. The latter approach 
> doesn't preclude providing a base or mixin class.