Best implementation for iTunes-like playlist structure?

Question

I'm creating an app that has a master-detail interface, similar to iTunes. It has the same data hierarchy as iTunes' playlists (except that I'm not allowing groups of "playlists" to keep things simple). In other words, there are normal playlists where their only items are added manually by the user. There are smart playlists, which show all items that match a user-defined predicate. Finally, there are some "playlists" that are not editable at all by the user (I call these DefaultFolders), but are in essence nothing more than fancy smart playlists in that their predicate is to show everything. These are like the "Library" and "Movies" sections in iTunes.

In my attempt to recreate this structure, I've come up with the following hierarchy (in Core Data): http://gallery.me.com/davedelong#100084/Screen%20shot%202009-11-07%20at%207.17.53%20PM&bgcolor=black (hopefully it is self-explanatory)

However, as I've gotten further into this app, this structure has become a little cumbersome. For example, I defined an accessor on the AbstractFolder class called -(NSSet *)items, so that all concrete folder types (DefaultFolder, SmartFolder, and Folder) can easily retrieve their contents. This coincides with the relationship that the Folder entity has with the Item entity. However, I can't implement the items accessor in AbstractFolder, because that would override the generated accessor provided by Core Data for the Folder entity. I've thought about making it part of a protocol that all concrete folders would implement, but that seems to defeat the purpose of inheritance.

So I open this up to the collective wisdom of the mailing list. Is there a better way I could model this structure? Have any of you worked on apps with similar structures? What did you find helpful?

Answer 1

Sorry, I haven’t used Core Data that much, but it’s not clear to me why you need to implement the items accessor in AbstractFolder? Can’t you just stick it in a category in the header and not bother to implement it? This is the standard approach for abstract methods.

For example, in AbstractFolder.h, you’d have:

@interface AbstractFolder (Abstract)

NSSet *items;

@end

and then you don’t bother to implement it anywhere—which will force the subclasses implementation to be used.

Answer 2

I've come up with a structure, which I detail in this answer: http://stackoverflow.com/questions/1812311#1812924