• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NEWBIE: Why use protocols?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NEWBIE: Why use protocols?


  • Subject: Re: NEWBIE: Why use protocols?
  • From: Ondra Cada <email@hidden>
  • Date: Wed, 18 May 2005 19:22:14 +0200

Ben,

On 18.5.2005, at 17:11, Ben D. Jones wrote:

This is a newbie question I'm sure, but I'm really not clear on this concept. Coming from a C background the concept of protocols isn't very clear.

(Formal) protocol is just a named list of messages. Declaring a conforming class you are (more or less) saying that it should have appropriate methods. That's all, there's no magic.


As a newbie, you can more or less ignore protocols for awhile: they are not used often in Cocoa, and they do not play important part in anything really interesting for a newbie.

Objective-C is my first truly OOP language and maybe I'm not understanding OOP correctly. My question is... if you have a class and protocol like this:

@interface MyClass : NSObject <MyProtocol> { @protocol UpDown
NSString *aString; - (void)increment;
} -(void)decrement;
- (void) doStuff; @end
- (id)doMoreStuff:(NSString *)withAString

Looks like this got kind of mangled up :)

isn't that clear enough to put the methods of that protocol in the MyClass def without the use of a protocol to "make sure it conforms to a protocol"?

Formal protocols are, well, formal. So is the conformance: you formally declare your class conforms to some protocols, and the conformsToProtocol: method tests this declaration, *not* whether the messages are really supported or not.


In fact, you can have a class A which *does* implement all the protocol methods, but does not conform to it (just since it was not formally declared so). On the other hand, you can have a class B which does conform to a protocol (since it was declared so), although it does not implement the methods! (That would raise a compiler warning, but till you actually try to send such a message it will work all right).

@protocol P
-(void)xxx;
@end

@interface A:NSObject @end
@implementation A
-(void)xxx {}
@end

@interface B:NSObject <P> @end
@implementation B @end // warning here, but all right till you actually send xxx


Or is there some type of implementation that I haven't run into yet in my projects where it would be important. Basically... I don't get why or when the use of a protocol is a must for clarity or function.

It is never a must, and seldom enough it is even convenient. That's why formal protocols are not too often used in Cocoa. As said above: for awhile, just forget them. Later, when you are cosy with the other ObjC features, you can *very* easily catch up with those few cases the protocols get handy.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc



_______________________________________________ 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
References: 
 >NEWBIE: Why use protocols? (From: "Ben D. Jones" <email@hidden>)

  • Prev by Date: Re: Why use protocols?
  • Next by Date: Re: CIImage - saving the file?
  • Previous by thread: Re: NEWBIE: Why use protocols?
  • Next by thread: Re: NEWBIE: Why use protocols?
  • Index(es):
    • Date
    • Thread