Question

I have several subclasses of UIViewController that I want to use a single category to give them all a couple of methods. The thing is I only want my classes not the base UIViewController to have that categories methods.

Say I have:

PanelAViewController
PanelBViewController
...

That I want to implement and respond to a class:

PanelAnimations

-(void)animateIn;
-(void)animateOut;

I could use a protocol and insert the methods each time but they use the same methods and values, so wouldn’t a category suit?

I am just not sure how to define the category for these custom classes.

Answer 1

Why you didn’t consider subclassing, instead of using categories or protocols? Here here you can simply create an AbstractViewController class (which heritates from UIViewController) that defines the panel animations methods, and then derive your own concrete controllers (PanelAViewController, PanelBViewController, etc.) from the abstract one.

The abstract class will define the methods and eventually some stubs in the implementation (is up to you if you want that PanelA and PanelB should call super or not). This depends on the abstraction degree you want to give to the abstract class. See the code example below.

Sometimes it is not clear if it is better to use a protocol or subclass or delegate mechanism. Most of the times the boundary is not clear and the final decision is more dependent on the programmer preference than a “codified” architectural rule. Typically you use protocol when you want different objects to have a common behavior for certain tasks (e.g.: you have a complex set of entities and one of these entities should be used as a map annotation: in such case you must simply provide this specific entity the MKAnnotation protocol compatibility); delegate is mostly used when you want to extend a class without subclassing it or without given the final user the possibility to subclass it. In your case I think subclassing is the most appropriate choice as all classes are strictly part of the same class hierarchy, they share a common code (or common interface) and provide each a specialized implementation.

//
//  AbstractViewController.h
//

#import 

@interface AbstractViewController : UIViewController

-(void)doAnimate;
-(void)didAnimate;

@end

//
//  AbstractViewController.m
//

#import "AbstractViewController.h"

@interface AbstractViewController ()

@end

@implementation AbstractViewController


-(void)doAnimate {
    NSLog(@"Abstract do animate");
}

-(void)didAnimate {
    NSLog(@"Abstract did animate");
}

//
//  ConcreteViewController.h
//

#import "AbstractViewController.h"

@interface ConcreteViewController : AbstractViewController

@end

//
//  ConcreteViewController.m
//

#import "ConcreteViewController.h"

@interface ConcreteViewController ()

@end

@implementation ConcreteViewController


-(void)doAnimate {
    [super doAnimate];
    NSLog(@"Subclass do animate");
}