• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: ADC Core Data article
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: ADC Core Data article
      • From: Marcel Weiher <email@hidden>
    • Re: ADC Core Data article
      • From: Scott Ellsworth <email@hidden>
    • Re: ADC Core Data article
      • From: Johnny Deadman <email@hidden>
References: 
 >Re: ADC Core Data article (From: Will Mason <email@hidden>)
 >Re: ADC Core Data article (From: Paul Szego <email@hidden>)
 >Re: ADC Core Data article (From: mmalcolm crawford <email@hidden>)

  • Prev by Date: Re: How to disable Spellcheck on NSTextView
  • Next by Date: Re: silly newbie obj-c question
  • Previous by thread: Re: ADC Core Data article
  • Next by thread: Re: ADC Core Data article
  • Index(es):
    • Date
    • Thread