Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The statement of the question seems little abstract to me, so please read the details below.

Since the time when C++ was the first choice Object Oriented Language for almost anything, we had a big problem of Multiple inheritance in C++ when two different implementations of same function declared or defined in a (abstract or concrete)parent class of the two, come to a common child class and create ambiguity, popularly known as the Diamond problem.

C++ gave a solution : the "virtual" keyword, to be used while specifying the parent class(es) so that only one copy goes to the final child class being decided at runtime instead of compile time based on certain rules.

Java tried to solve this by providing single inheritance and avoiding multiple inheritance completely.

But then it lacked a feature where a class behaviour could be influenced by a bit and that may change in future or more behaviour may be added to it and we needed a way to encapsulate behaviour, then came the construct "interface" which had nothing but method declarations which each implementing class had to implement in their own way.

Protocols in Objective C are more or less the same thing.

However this approach has a major drawback, and this is where my question comes into picture.

The drawback is, if a class has many subclasses implementing the same interface in the same way. The same code has to be written everywhere in each class.

If it was all the classes, then the implementation could have been there in the parent class which gives the implementation.

At max what can be done is to introduce a class with the implementation of the common method in between the current parent class and make all those classes inherit from it.

But this can lead to lot of bugs if not done properly in a complex project.

Scala provides Traits which not only serve as interfaces but can add full blown implementations for few of them that can be mixed with some classes that require it and removed when not.

I haven't seen the syntax but I have heard that Ruby solves the same problem using something called as mixins.

In case of Objective C, we have protocols but they have the same limitations as Java interfaces.

So my question is, If I create a category of a class and import it in any subclass of that class, Will the subclass get all those implementation methods? Also if I remove it, will it be synonymous to removing the trait inclusion declaration for a class?

I might be wrong in any of my assumptions above, I am newbie when it comes to OOP design (and just got interested in FP).

I would also appreciate any better solutions than this one.

share|improve this question
    
"protocols in Objective C are more or less the same thing." – Not just more or less. Objective-C was the main inspiration for Java, Objective-C protocols and Java interfaces are exactly the same thing. –  Jörg W Mittag Jan 25 '13 at 11:10
    
I kept that "more or less" for "@optional" method implementation feature in Objective C. Also the "moe or less" includes that static final vars that an interface in java can accomodate. So the "more or less" was just in case ....someone says NO..they dont ..here is the difference..... etc –  Amogh Talpallikar Jan 25 '13 at 11:17
    
@JörgWMittag: BTW what do u think of the category solution. Is it a good idea ? –  Amogh Talpallikar Jan 25 '13 at 11:19

1 Answer 1

up vote 2 down vote accepted

Importing (#import ...) an Objective-C category adds the methods defined in that category to all instances of the class on which the category was defined. Other than with traits which can be mixed into classes selectively a category extends the class on which it was defined once and for all.

Also you can not create a standalone category and mix that into several different classes. A category is an extension for a specific class, similar as if you would add the methods to the class itself.

Traits are like java interfaces but with implementation. Wether a trait can be mixed into a class depends not on the classes name but on the methods the class provides. If a class has the methods a trait needs, the trait can be mixed into that class.

share|improve this answer
    
Trait is definitely powerful feature. But I was just thinking about classes in the same category. If the import only happens in the .m of class. Will the child class get it ? and will the subclasses of the child class be the only classes to get the implementation because if that works I can make a category of NSObject itself and make sure that I should be able to add the category to any class (except for the ones not inheriting from NSObject ? because anyways we have to import the category along with the original class wherever we need it. –  Amogh Talpallikar Jan 25 '13 at 11:32
1  
What you want is not possible with categories. Let me quote from apples "programming with objective-c": A category can be declared for any class, even if you don’t have the original implementation source code (such as for standard Cocoa or Cocoa Touch classes). Any methods that you declare in a category will be available to all instances of the original class, as well as any subclasses of the original class. At runtime, there’s no difference between a method added by a category and one that is implemented by the original class. –  jmaschad Jan 25 '13 at 11:51
    
Thanks. Got it :( In such cases where I am writing same code again and again in the implementations of subclasses , A,B,C,D over-riding a method m of a parent class O which implements protocol P in a way but different from FGHI which dont want to override it. Then the only option remains is to include a new class X which will subclass O and override a common method "m" there and let A,B,C,D inherit from it instead of O directly ? –  Amogh Talpallikar Jan 25 '13 at 11:57
    
I think that would be the classical case for another level of inheritance. As long as your inheritance hierarchy doesn't get too crazy i think it is a nice solution. –  jmaschad Jan 25 '13 at 12:07
    
Thanks a lot and sorry again for an off-putting statement which was there initially :) –  Amogh Talpallikar Jan 25 '13 at 12:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.