CODEWITHSUNDEEP
objective-cprotocols
RK-
RK-

Reputation: 12211

Why do we need protocol in objective C?

The necessity for protocols are to abstract the methods of classes which are not hierarchically related.

The similar things also can be done with the help a class (interface) which encompasses all those methods and subclass them ? (This is not really possible due to the Multiple inheritance problem since a class has to be derived already from NSObject.ignore the NSProxy case)

What special things that protocols can do than a class?

Are protocols trying to solve only the multiple inheritance problem?

Upvotes: 0

Views: 2445

Answers (3)

vikingosegundo
vikingosegundo

Reputation: 52227

Protocols main advantage is, that they describe what a object should be able to do, without enforcing subclassing. In languages that dont have multiple inheritance such a mechanism is needed, if you want others programmers be able to use your classes. (see delegation)

For an instance Java has something similar, called interfaces.

This means a huge advantage, as it is very easy to build dynamic systems, as I can allow other developers to enhance my classes via a clearly defined protocol.

A practical example:
I am just designing a REST API and I am providing a Objective-C client library.
As my api requires information about the user, I add a protocol

@protocol VSAPIClientUser <NSObject>
-(NSString *)lastName;
-(NSString *)firstName;
-(NSString *)uuid;
@end

Anywhere I need this user information, I will have an basic id-object, that must conform to this protocol

-(void)addUserWithAttributes:(id<VSAPIClientUser>)user;

You can read this line as: "I don't care, what kind of object you provide here, as long as it knows about lastName, firstName and uuid". So I have no idea, how the rest of that object looks like — and I don't care.

As the library author I can use this safely:

 NSDictionary *userAttributes = @{@"last_name" : [user lastName],
                                  @"first_name": [user firstName],
                                        @"uuid": [user uuid]};

BTW: I wouldn't call the absence of multi-inheritance a problem. It is just another design.

“[…] If I revisited that decision today, I might even go so far as to remove single inheritance as well. Inheritance just isn’t all that important. Encapsulation is OOP’s lasting contribution.” — Brad Cox was asked, why Objective-C doesn’t have multiple inheritance. (Masterminds of Programming: Conversations with the Creators of Major Programming Languages, p. 259)

Upvotes: 4

Phillip Mills
Phillip Mills

Reputation: 31016

As an alternative view....

Object-oriented programming's most basic value comes from being able to model real-world relationships directly as opposed to translating them into abstract and vaguely-equivalent computer-world constructs. Wherever a language requires you to think about the implementation of a solution in different terms than those you can use to describe your problem, it is flawed as an OOP tool. (Note that I didn't say 'useless'. :) )

Real-world objects have various roles that depend on context. Those roles can have state. Therefore, I agree that lack of multiple-inheritance is an impediment to ease of modelling. Objective-C protocols, Java interfaces, and the claim that you should prefer composition to inheritance are all denials of a fundamental part of the OOP advantage.

Upvotes: 1

Jirka Hanika
Jirka Hanika

Reputation: 13529

One of many uses of C++ abstract classes is, among their other uses, to define interfaces (to specify reusable contracts). There are however also other programming languages, such as Objective C that have a separate concept for interfaces in this sense; in Objective C, it is called protocols.

A wide use of such a construct does require a way of attaching more than one contract to an object; and if such interfaces are allowed to inherit from each another, this has to be multiple inheritance to be useful.

However, this is not the same thing as multiple inheritance between classes.

Protocols are not trying to solve the multiple inheritance problem. They are trying to separate contract specification from object (data+code) specification. They can actually do much less than a class (if you ignore the multiple inheritance aspect) and that's why they exist as a separate concept.

Implementing a protocol is generally a much less restrictive (safer) proposition to consider than inheriting from a class.

Upvotes: 0

Related Questions