Re: Newbie design question: protocol vs. delegate vs. class-cluster
Re: Newbie design question: protocol vs. delegate vs. class-cluster
- Subject: Re: Newbie design question: protocol vs. delegate vs. class-cluster
- From: Magnus Strand <email@hidden>
- Date: Thu, 10 Feb 2005 12:21:01 +0100
Hi,
I think you can use a protocol like this:
@ interface AbstractBar: NSObject
- (void)method1;
- (void)method2;
@end
Then you can subclass this protocol:
@ interface Bar: AbstractBar
- (void)method1;
- (void)method2;
@end
@ interface Bar1: Bar
- (void)method1;
@end
Your Foo object can then call different Bar objects Bar1, Bar2 etc
through an AbstractBar*.
From the docs:
Setting up a protocol. A class can declare a number of methods that its
subclasses are expected to implement. The class might have empty versions of
the methods, or it might implement partial versions that are to be
incorporated
into the subclass methods. In either case, its declarations establish a
protocol
that all its subclasses must follow.
When different classes implement similarly named methods, a program is
better
able to make use of polymorphism in its design. Setting up a protocol that
subclasses must implement helps enforce these conventions.
Magnus
Jim McLoughlin wrote:
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
--
*Magnus Strand *
Systemutvecklare | System Developer, MSc
*Teknik i Media* | Södra Förstadsgatan 2 | 211 43 Malmö | Tel +46 40 601
57 00 | Fax +46 40 601 57 99
Direkt +46 40 601 57 16 | Mobil +46 704 20 57 16 | email@hidden
| www.tim.se
/This message contains information that may be privileged or
confidential and is the property of Teknik i Media. / /It is intended
only for the person to whom it is addressed. If you receive this message
in error, please notify the sender immediately and delete all copies of
this message. /
_______________________________________________
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