On 10 Mar '08, at 8:06 PM, Ben Lachman wrote:
I don't know if I agree with the working with the APIs bit. I think it's obvious that the APIs expect a single delegate to be able to handle multiple objects using it concurrently, thus the passing of the object that is delegating to the delegate.
It's an API design rule that delegate/data-source APIs should allow the same delegate to work with multiple delegatees.
But that doesn't mean you should always do things that way. Sometimes it's appropriate, sometimes not. If you have to resort to setting up dictionaries to associate state with the objects, I think that's an indication that you haven't factored your design correctly.
Creating 15 delegate objects over and over again (in my case every time a user does a search, submit, etc.) doesn't seem to be a very clean solution as it spreads your networking code out. You'd basically have to have a class that starts your connections and then have another class that is the connection's delegate and then possibly have one of those two classes, or another one, handle cleaning up or whatever
Not really — I'd do it with one "Downloader" class that downloads one resource. Its -init method creates an NSURLConnection, makes itself the delegate, and starts it. The class has instance variables for all of the state associated with the download. When the download finishes it cleans up, and either posts a notification or sets an observable property.
I've implemented this pattern so many times I've lost count :) The NSOperation class in Leopard is basically a generalization of the skeleton of this.
How to divide a program into objects/classes is a subjective matter, to be sure. But I've been doing it for a very long time [I started using Smalltalk-80 as a summer intern at Xerox in 1984], and the most common mistake I see people make in their code is to shove too much stuff into a single class. When one object instance starts to represent a bunch of different conceptual objects, it's good to think about splitting it.
—Jens
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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 [EMAIL PROTECTED]
