Newbie design question: protocol vs. delegate vs. class-cluster
Newbie design question: protocol vs. delegate vs. class-cluster
- Subject: Newbie design question: protocol vs. delegate vs. class-cluster
- From: Jim McLoughlin <email@hidden>
- Date: Wed, 9 Feb 2005 17:06:08 -0800
Hi
I'm taking my first stab at using objective-c to develop a reusable
framework (no gui/interface elements).
Let's say there are two main API classes, Foo and Bar. Foo uses a Bar
object, and expects Bar to provide several methods. Their are several
specialized version of Bar objects (e.g. Bar1, Bar2, Bar3) that should
all be usable by Foo.
If I was developing in Java, I would create a Bar interface. So my
first inclination was to create a Bar protocol. However, I started to
realize that there were relatively few formal protocols defined in the
Cocoa APIs, and don't see much mention of them in cocoa books /
articles.
My other options are:
1) Class-cluster: I like this pattern, but it only seems appropriate if
API users only need to interact with Bar. In many cases, they will
want to configure Bar1, Bar2, Bar3 objects, or define their own Bar
implementations.
2) Delegate/Informal Protocols: I'm familiar with delegates from the
AppKit frameworks, are they a common pattern in business logic? If so,
from the docs, I see that I define the informal protocol as:
@ interface NSObject(Bar)
- (void)barMethod
@end
What I don't understand is why I even have to define the above. I
can't use the above definition to do something like:
@ interface Foo
- (void)setBar:(Bar *)myBar
@end
so why bother defining the informal protocol at all? If I still have
to pass around id's and check for compliance on a method-by-method
basis, is it purely for documentation purposes?
Regards,
Jim M
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden