I need to design a plugin architecture similar iPhoto and Aperture's export plugins, but I'm puzzling over the design pattern that Apple used. I hoping somebody could help shed some light on the advantages to the approach taken by Apple.
The pattern that Apple uses for both programs is to have an ExportManager of sorts that the plugin queries to determine the properties of photos at a given index. This means that in the headers there are a whole bunch of methods that look like
- (id) somePropertyAtIndex: (unsigned) index
for dozens of different properties like the image size, path, thumbnail, rating, and so on.
This pattern is in contrast to what I would intuitively use where the ExportManager would basically just hand an array of Photo objects to the plugin. The Photo class would then define these same properties. This seems like the more cocoa-like way of doing things, so I assume there must be a real advantage to Apple's approach.
The only advantage that I can think of for Apple's approach is that it might scale better. In the case where you have 10,000 photos that are trying to be exported, none of the data needs to be loaded into memory until it's actually asked for. On the other hand, my approach wouldn't use much more memory either if it returns proxy objects (like CoreData) that don't actually fetch the data until asked for either.
Anybody have any additional insight?