On Mar 11, 2008, at 10:42 AM, Jens Alfke 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.
My point was just that doing things this way isn't really working
against the API. As you say yourself this is the API's design rule.
I don't deny that it may be better in some cases to factor your code
differently, just that it isn't counter to the API.
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.
This seems fair. At some point when I'm a bit less busy I'll try it
with my code. :-)
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.
Maybe I just don't have this problem too often. I really dislike
huge classes and tend to have more issues with ending up with
multitude of small close to empty class files than the other way
around. I've only been seriously coding this century though, so
we'll see what I have to say in another few decades.
Cheers,
->Ben
--
Ben Lachman
Acacia Tree Software
http://acaciatreesoftware.com
[EMAIL PROTECTED]
740.590.0009
_______________________________________________
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]
