On Apr 1, 2011, at 12:47 PM, Chris Markle wrote: > WT, > > Thanks for the code!
Hello again, Chris. You're most welcome! > So of the approaches: > >>> 1. delegates >>> 2. blocks >>> 3. KVO >>> 4. Notifications > > you went with delegates (didFinishDownloadingData: and > failedWithError:) for completion notification. > > Has this worked out well for others that have used this code? I can't speak for other people but delegation for situations such as this one has served me well in numerous occasions. > Did you consider any of the other alternatives and if so what made you go with > the delegate approach? I didn't exactly consider the other alternatives since delegation is the standard approach when one needs to offload work to other objects, but if I had to defend why delegation is the best approach in this case, here's what I'd say: KVO, as I understand it (I'm not very experienced with the KVO/KVC technologies), is best suited to observe changes in object *properties*, and not so much as a means to offload work to another object. The blocks API is great but it doesn't lend itself easily to much reusability. Sure, you can create a block, give it a name, and pass it around, but you don't want your block to have a ton of code. If you look at the majority of examples of block use, blocks are typically small sections of code. Besides, at the time I wrote the Downloader class, I wasn't aware of the blocks API (it was before WWDC 2010). Notifications are best suited for situations when a potentially large number of objects may be interested in an event or situation caused by a single object and you don't want to couple the producer to the consumers of those events. In my particular case (which happens to be *very* common), my goal was very clear: I had a table view controller managing a table view and I needed to fill the rows of that table view with data coming from the web. Since each row would have different data, I needed a means of independently downloading different bits of data. Of course, I could have written all the downloading code inside my custom table view controller class, but that's not a very reusable approach. Moreover, I'm a firm believer that each class should have as few and as well-defined responsibilities as possible. Writing all the downloading code inside the table view controller class would clutter the table view controller class with too many responsibilities. Much better is to create a class with the single responsibility of managing downloads in such a way that each instance is responsible for downloading data from a single url. But, then, how to coordinate the responses so that, when each downloader object is done or fails, the table view controller gets notified? Note that in this case we have several producers (the downloader objects) and one consumer (the table view controller), rather than one producer and several consumers. The notification approach is best used in the latter case. So, the natural approach here is to make the one consumer (the table view controller) the delegate of each of the producers (the downloaders). To summarize the advantages, you get code reusability, division of class responsibilities, decoupling of classes (the Downloader class knows nothing about the table view controller class), and you solve the many-producers/one-consumer problem in a natural and simple way. If I may make a suggestion, I think you might benefit from reading Cocoa Design Patterns by Erik Buck and Donald Yacktman a book that goes into great detail on the various so-called design patterns commonly used in Cocoa and Cocoa Touch programming. Hope this helps. WT_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
