Changing superclasses


#1

I may have missed the explanation earlier in the book but why are we changing superclasses from (ex. NSObject to UIView) or (ex. NSObject to UIViewController) instead of just starting the class with that as its super class already?


#2

This is very important: A class chooses to adopt another class as its superclass on the basis of what functionality it wants to inherit from that superclass.

Therefore when writing code for a graphical user interface, it is very rare that your classes inherit from NSObject unless you can’t use one the existing UI classes and you have to create your own UI class.


#3

The reason they first let you choose to create a subclass of NSObject is because of what is discussed at pretty much the very beginning of the book.
If you subclass from UIView(Controller) you get a lot of “boilerplate” code which they want you to find out about and type in for yourself, if necessary.
By subclassing NSObject and then changing the superclass to the appropriate class you would get the least amount of boilerplate code.

I imagine that in a real life world situation you would probably just subclass the correct class from the word go.


#4

[quote=“Arthurzwit”]The reason they first let you choose to create a subclass of NSObject is because of what is discussed at pretty much the very beginning of the book.
If you subclass from UIView(Controller) you get a lot of “boilerplate” code which they want you to find out about and type in for yourself, if necessary.
By subclassing NSObject and then changing the superclass to the appropriate class you would get the least amount of boilerplate code.

I imagine that in a real life world situation you would probably just subclass the correct class from the word go.[/quote]

Thanks so much, I don’t remember reading this part. Guess I need to read over it again!


#5

[quote=“slassen”][quote=“Arthurzwit”]The reason they first let you choose to create a subclass of NSObject is because of what is discussed at pretty much the very beginning of the book.
If you subclass from UIView(Controller) you get a lot of “boilerplate” code which they want you to find out about and type in for yourself, if necessary.
By subclassing NSObject and then changing the superclass to the appropriate class you would get the least amount of boilerplate code.

I imagine that in a real life world situation you would probably just subclass the correct class from the word go.[/quote]

Thanks so much, I don’t remember reading this part. Guess I need to read over it again![/quote]

Yes, Arthurzwit is entirely correct. Apple can sometimes add a lot of boilerplate code when creating a direct subclass. We first mention it, as far as I can tell, in the View Controller chapter that we’ll subclass NSObject to avoid this boilerplate code. Even when I’m doing normal consulting development, I often go down this route (of changing the superclass). For example, if you subclass UITableViewController, there is a ridiculous about of boilerplate code and warnings that Apple puts in, and I immediately delete it all. In the context of the book, starting “from scratch” helps to understand how all of the pieces come together.