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: Gorazd Krosl <email@hidden>
- Date: Thu, 10 Feb 2005 09:53:07 -0500 (EST)
> Message: 13
> Date: Thu, 10 Feb 2005 12:21:01 +0100
> From: Magnus Strand <email@hidden>
> Subject: Re: Newbie design question: protocol vs. >
> delegate vs.
> class-cluster
> To: Jim McLoughlin <email@hidden>
> Cc: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; > >
format=flowed
Hi,
This is an situation when protocols come in. Protocol
is a way to promise that you implement a certain
In: AbstractBar.h
@protocol AbstractBar <NSObject>
- (void)method1;
- (void)method2;
@end
Then in Bar1.h
#import "AbstractBar.h"
@interface Bar1 <AbstractBar>
- (void)method1;
- (void)method2;
@end
followed of cource by implementation in Bar1.m
Then in your Foo.h you only need to import your
"AbstractBar.h" file and declare in
@interface Foo : NSObject
{
- id <AbstractBar> bar;
}
- (void)setBar:(id<AbstractBar>)aBar;
@end
Your Foo.m file does not need to know about all of
your different implementations of Bar1 ... BarN, since
the interface was declared in the protocol. Also in
your setter method above, you can check, if the
incomimg object is actually implementing the protocol:
if (![aBar conformsToProtocol:@protocol(AbstractBar)])
[self raiseTheHell]
Your Foo class then knows only about the interface and
does not need to know anything else about the Bar
objects. Also nice, the Bar objects do NOT need to be
related, they only need to implement the protocol
interface promised. That means, you do not need to
create a common root class for them, they can be
descendants of completely different classes (one can
be subclass of a NSView and other from NSCell for
instance).
Hope that helps
Gorazd
> 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
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
_______________________________________________
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