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.

  • "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. Jan 25, 2013 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 Jan 25, 2013 at 11:17
  • @JörgWMittag: BTW what do u think of the category solution. Is it a good idea ? Jan 25, 2013 at 11:19

1 Answer 1


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.

  • 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. Jan 25, 2013 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. Jan 25, 2013 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 ? Jan 25, 2013 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. Jan 25, 2013 at 12:07
  • Thanks a lot and sorry again for an off-putting statement which was there initially :) Jan 25, 2013 at 12:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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