When to call or not call "super's method"?


#1

In the book, I see some methods such as viewDidLoad and initWithFrame call its super methods. On the other hand, others such as loadView and drawRect don’t. Could anyone explain when we are supposed to call super’s method, and when to not? Thanks.

-(void)viewDidLoad
{
    [super viewDidLoad];
    ... ...

#2

The best place for this information is the iOS documentation itself. As an example, see the notes for UIViewController’s viewWillAppear: (https://developer.apple.com/library/ios/documentation/uikit/reference/UIViewController_Class/Reference/Reference.html#//apple_ref/occ/instm/UIViewController/viewWillAppear:).

The documentation in itself might not be exhaustive, which is why you’re reading this book in the first place.


#3

So, we need to refer to books and apple docs for each method whether to call super’s one or not. Thanks.


#4

I think we will call if we just want to add more behavior after what the function is expected to do.
We will not call if we want to develop ourself the whole function which is much different from the original function


#5

Typically, the reason why you’ll see code that calls super’s method is because you’re overriding that method in a subclass, but you only want your override to add behavior to the original super method. For example, in the viewDidLoad case, anything you add in your override after calling super’s viewDidLoad will be done in addition to that. You don’t need to know what super’s viewDidLoad method does. You just need to make sure you call it in your override, and then add whatever custom behavior you want after that.

I think that learning when to call super’s method is just a matter of experience. But it’s safe to say that overriding is one area where you’re most likely to see it. And all it means in most cases is that you’re duplicating functionality of the superclass’s method, and then adding your own custom behavior into the mix. The reason why programmers do this is so they don’t have to duplicate code, which would introduce all sorts of problems with keeping things consistent over time as a project becomes larger. They can simply override a super method, reuse the perfectly good code that already exists, and add more on top of that which will just be specific and tailored to the subclass. If the code executed in the super’s method ever needs to be changed, it will only need changing in one place.