| 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.
|