2

Why would I want to use a protocol rather than create a subclass and inherit the methods..?

Please explain it to me, i'm to confused about this topic, i'm not very pleased with the explanation in the book im reading.

Where do I use protocols instead of other ways to get the methods..? if I can subclass a class and get the methods why would i want to use a protocol where i need to define the methods?

MNY
  • 1,506
  • 5
  • 21
  • 34
  • There's lots of other explanations out there. Can you elaborate on what you do and don't understand? – jscs Feb 18 '13 at 18:57
  • Where do I use protocols instead of other ways to get the methods..? if I can subclass a class and get the methods why would i want to use a protocol where i need to define the methods? @JoshCaswell – MNY Feb 18 '13 at 18:59
  • Please edit your question to elaborate. – jscs Feb 18 '13 at 19:00
  • no, it's not a duplicate. im not asking what is it. why is it better then, and where is it more commonly to be used @JoshCaswell – MNY Feb 18 '13 at 19:01
  • Without the explanation of _exactly_ what you don't understand, the only way anyone can reply is by giving a full description. – jscs Feb 18 '13 at 19:03
  • I agree that what a protocol/interface is and why you'd choose interfaces over inheritance are not the same question. More importantly, although the answers to [What is a Protocol?](http://stackoverflow.com/q/3981832/643383) do a good job of explaining *what*, they really don't address *why*. Voting to reopen, although it wouldn't surprise me if there's some other, more duplicative duplicate out there already. – Caleb Feb 18 '13 at 19:26

3 Answers3

6

Why would I want to use a protocol rather than create a subclass and inherit the methods..?

Protocols make it possible for unrelated classes to all implement the same interface. Instances of each of those classes can then be used by a client of the protocol. For example, UITableViewDataSource is a protocol that provides an interface by which a table can ask for data from any object that implements the protocol. The table view doesn't care what the type of the object is so long as it implements the data source interface.

Imagine how unpleasant things would be if all table data sources had to inherit from a common class! Objective-C only provides single inheritance, so you'd effectively be constrained to using only a single kind of object for your data source. With protocols, though, a data source can be a view controller, a model object, or perhaps even a remote object.

To be more specific, protocols allow a form of polymorphism. That means that a single object can take several forms: e.g. view controller, table data source, table delegate, scroll view delegate. Because Objective-C is a single-inheritance language, you only get one of those interfaces via inheritance. The rest you implement yourself, but that often makes sense because you generally adopt a given protocol in order to customize some other object's behavior anyway.

Caleb
  • 124,013
  • 19
  • 183
  • 272
0

Because subclassing and protocols are two different things. Subclassing extends a class with new functionality while inheriting all previous functionality of a specific class while a protocol, when applied to a class, simply adds functionality to it and doesn't inherit anything from it; what that class is usually doesn't matter.

Protocols are most frequently used for the delegate pattern in Objective-C whereby an object can send a message to another object without caring WHAT that object is (i.e. it's class).

Often times, a delegate is declared as:

 @property(nonatomic, assign) id < MyObjectDelegate > delegate;

Notice that the class of the property is id -- in essence, you don't care if the object is a car or a turtle -- all you need to know is that it is an object (id) and that it contractually subscribes to the functions you need it to. So if your delegate is type turtle, you can call [delegate myStateChanged]; or, if your delegate is a car, you can call [delegate myStateChanged]. All you need to know is that, if you send a message to it, it will accept it.

I would look up and read about the use of Objective-C delegates as I think it will really help you understand protocols better and how it's different than subclassing. I don't know if you're familiar with other, object-oriented programming languages, but if so, protocols are most similar to Interfaces in other languages.

CJ_912
  • 67
  • 2
  • 1
    Protocols do not add any functionality to a class. A protocol only defines an abstract interface. – rmaddy Feb 18 '13 at 19:09
  • Yeah, I suppose that is true, but I couldn't think of a better way to state it. The idea is roughly equivalent though -- it provides a way for a class to handle some message – CJ_912 Feb 18 '13 at 19:10
  • 1
    I reworded it to state "when applied to a class" because yes, by itself, a protocol does nothing but define. – CJ_912 Feb 18 '13 at 19:12
  • No, a class implements functionality regardless of whether it happens to implement methods that are also defined in some protocol or not. The protocol is just a way to abstract out the implementation and to state - this object has a certain set of methods. – rmaddy Feb 18 '13 at 19:14
  • @CJ_912 thanks allot buddy. The next subject in the book is about delegates :) – MNY Feb 18 '13 at 19:15
  • @CJ_912 Applying a protocol to a class does not add any functionality to the class. The class would work exactly the same without the protocol. Applying a protocol to a class is simply a marker telling other classes that the class has a certain interface. – rmaddy Feb 18 '13 at 19:17
  • I don't think I've ever stated that a class doesn't implement any functionality before an interface is applied to it -- only that the interface itself adds publicly defined message to the class to which it is applied while not inheriting the functionality of the class itself. – CJ_912 Feb 18 '13 at 19:20
  • @CJ_912 No, a protocol adds nothing. You keep saying that a protocol adds functionality and now you say it add "publicly defined message" to a the class. It does neither. Remove the protocol and the class doesn't change in any way. Add the protocol and the class doesn't change in any way. It is simply a marker. – rmaddy Feb 18 '13 at 19:30
-2

Protocols are useful because you can implement many protocols, instead you can only extend a single class.

Emanuele Paolini
  • 9,912
  • 3
  • 38
  • 64