Re: NSURLDownload and userInfo
Re: NSURLDownload and userInfo
- Subject: Re: NSURLDownload and userInfo
- From: Jens Alfke <email@hidden>
- Date: Tue, 11 Mar 2008 07:42:29 -0700
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden