macOS Subclass of a class question

[larswik]

I am reading "Objective-C for absolute beginners" and have an OOP question. I created a new project called "bookstore" and then went to create a new class by FILE/NEW FILE "Objective - C Class".

My question is. Why must I make it a "Subclass" of another class, in the case of the book NSOBJECT? If I understand it right my subclass inherits all the METHODS of the SUPER CLASS (If I got my terminology right that is)?

Do all classes I create need to inherit from a parent or super class?

Thanks,

-Lars

 

[gnasher729]

I am reading "Objective-C for absolute beginners" and have an OOP question. I created a new project called "bookstore" and then went to create a new class by FILE/NEW FILE "Objective - C Class".

My question is. Why must I make it a "Subclass" of another class, in the case of the book NSOBJECT? If I understand it right my subclass inherits all the METHODS of the SUPER CLASS (If I got my terminology right that is)?

Do all classes I create need to inherit from a parent or super class?

In theory, no. In practice, yes.

There is an awful lot of functionality in NSObject that you absolutely don't want to do without. It starts with the alloc class method which is inherited from NSObject - without alloc you are already quite stuck. It goes on with retain and release. If you ever wanted to create a class that is not directly or indirectly derived from NSObject you'd have to learn an awful lot of very low level details of Objective C to get this working.

 

[jiminaus]

EDIT: gnasher729 bet me to it .

If you still have it, read Kochan 2nd ed pp 157-158 ("It all begins at the root").

 

[larswik]

Thanks guys, I am kinda if'y about this new book. It is detailed in some areas and not so much in other parts.

So in the real world I could be a class and my mother would be a super classy person (super or parent class). If I don't know something myself, I would check with my mother for that information. I could use the super class knowledge on how to INIT an object then without having that information in my class.

Is my understanding of that relationship kind of on target?

jiminaus - I still have his book and I will read up on those pages for more detail.

Thanks!

-Lars

 

[jiminaus]

So in the real world I could be a class and my mother would be a super classy person (super or parent class). If I don't know something myself, I would check with my mother for that information. I could use the super class knowledge on how to INIT an object then without having that information in my class.

Yes. Lets say your mother is an artist, and you have inherited from her. You can do anything your mother can do. If your mother can paint, so can you. If your mother can draw, so can you. But you don't need to ask. Unless you take steps do otherwise, you will automatically do as your mother does.

Back in Objective-C, lets say someone sends you a description message. If your class don't have a description method, then the Objective-C runtime will look for a description method in your superclass (your parent class). If it doesn't find it in your superclass, then it looks in the superclass of your superclass (your grandparent class). It continues looking up the inheritance hierarchy checking for a description method in all your class's ancestors, until the runtime hits the root (NSObject). It'll turn out the NSObject will have a description method, so that's what will be executed if nothing else in overrides it by providing its own description method.

Terminology note: The terms superclass and parent class are the same. You can use whichever is natural to you. There's no need to say superclass or parent class. Similarly the terms subclass and child class are the same.

 

[larswik]

jiminaus - Thanks for the detail explanation!

I am putting the book down for the night. I just hit a part of the book where it showed 'self = [super init]'. The explanation was hard to grasp and it is late, it's a question from tomorrow.

Thanks!

-Lars

 

[Phil A.]

Wirelessly posted (iPhone 4: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3 like Mac OS X; en-us) AppleWebKit/534.32 (KHTML, like Gecko) Version/5.0.2 Mobile/8F190 Safari/6533.18.5)

Think of the subclass to class as an "is a" relationship. In other words, a blackbird could be a subclass of a bird because it "is a" bird. In other words, a subclass takes all the traits of its parent class and then adds detail. I would say your example of being a subclass of your mother isn't really a valid oo class relationship.

 

[jiminaus]

Think of the subclass to class as an "is a" relationship. In other words, a blackbird could be a subclass of a bird because it "is a" bird. In other words, a subclass takes all the traits of its parent class and then adds detail. I would say your example of being a subclass of your mother isn't really a valid oo class relationship.

I really do feel for people getting started in object-orientation. It's perfectly natural once you get it, but it takes a lot of mental anguish beforehand. As an industry, we don't help sometimes with out choice of terminology.

 

[larswik]

I do get the concept of classes and objects being created from classes, like houses are built from blue prints. Objects created from the same class can be different but share the same traits like 'OBJECT 1 home address 1122' and OBJECT 2 home address 1234'. The object's home address are different but they are created from the same class, or blueprints.

I can then send MESSAGES to the METHODS within OBJECTS. If the METHOD is found it returns the answer. If it is not found it will travel to the PARENT CLASS, GRANDPARENT CLASS and so on to find the METHOD the MESSAGE was sent to. I think this is called 'Dynamic Binding'.

That raises a question. When I compile and run my code Objects are created from my classes and stored in memory. Does this also mean behind the scene that the parent, grandparent and so on classes are also turned into objects from classes (homes from blue prints)? So when I send a message to a method in my object, and it is not found, will it then search, from my object, to the parent class or parent objects?

-Lars

 

[gnasher729]

I do get the concept of classes and objects being created from classes, like houses are built from blue prints. Objects created from the same class can be different but share the same traits like 'OBJECT 1 home address 1122' and OBJECT 2 home address 1234'. The object's home address are different but they are created from the same class, or blueprints.

I can then send MESSAGES to the METHODS within OBJECTS. If the METHOD is found it returns the answer. If it is not found it will travel to the PARENT CLASS, GRANDPARENT CLASS and so on to find the METHOD the MESSAGE was sent to. I think this is called 'Dynamic Binding'.

That raises a question. When I compile and run my code Objects are created from my classes and stored in memory. Does this also mean behind the scene that the parent, grandparent and so on classes are also turned into objects from classes (homes from blue prints)? So when I send a message to a method in my object, and it is not found, will it then search, from my object, to the parent class or parent objects?

You can send messages to objects (or instances of a class), these methods are called instance methods.
You can send messages to classes, these methods are called class methods. (- and + in front of the methodname).

Objective-C then looks for a suitable implementation of the method. It first checks whether the class of the instance (for instance methods) or the class itself (for class methods) implements the method. If it doesn't, then it checks the superclass, the superclass of the superclass, and so on until it reaches a class without superclass, like NSObject. At that point it sends a special message (named something like "unimplemented") to the object. If that fails as well then an exception is raised.

There are no "parent objects". If you create an instance of a class that is derived from a class that is derived from a class that is derived from a class that is derived from a class that is derived from NSObject, then only one object is created. That object contains all the instance variables of all those classes.

 

[larswik]

gnasher729 wrote - "That object contains all the instance variables of all those classes. "

Gotcha. I see how that works now.

Thanks,

-Lars

 

[jiminaus]

I can then send MESSAGES to the METHODS within OBJECTS. If the METHOD is found it returns the answer. If it is not found it will travel to the PARENT CLASS, GRANDPARENT CLASS and so on to find the METHOD the MESSAGE was sent to. I think this is called 'Dynamic Binding'.

The process of finding a method in response to sending a message to an object is a type of binding. That binding can occur at two points in time: while the program is being compiled (compile-time), or while the program is running (run-time).

Dynamic binding is when the binding happens at run-time. Static binding is when the binding happens at compile-time. Objective-C is a dynamic binding language, it doesn't have static binding. Some languages are static binding languages, they don't have dynamic binding. Other languages are dual binding languages (C++ is the notorious example), where you'll have static binding in some contexts, and dynamic binding is other contexts.

What you're talking about is simply method inheritance. Method inheritance is implemented using dynamic binding in Objective-C. But static binding languages (or static binding contexts of dual binding languages) will work in the same way in this regard.

So what's the practical difference between dynamic method binding and static method binding?

Imagine a class called Shape. It has a method called draw, but it does nothing.

Image another class called Circle. Circle inherits from Shape, that is Circle's superclass is Shape. Circle also has a method called draw, which draws a circle. Circle's draw method OVERRIDES the draw method inherited from Shape.

Now consider the following psudeo-code (don't read any language's semantics into this):

Circle circle = // Alloc and init a Circle object here
Shape shape = circle;
[shape draw]; // What happens here? Nothing, or a circle?

So what happens? Is nothing drawn because shape's type is Shape and Shape's draw method does nothing? Or is a circle drawn because while shape's type is Shape, actually shape is a Circle and Circle's draw method draws a circle? The answer depends on the type of method binding.

With dynamic method binding, the runtime will find shape's actually class and start looking for a method there. So in dynamic binding, this code will draw a circle.

With static method binding, the compiler will see shape as being a Shape, will not know that it's actually a Circle object, and will look for a draw method starting with Shape. So in static binding, this code will draw nothing.

At first we only had static binding languages. Then we had dynamic binding languages, discovered this kind of POLYMORPHISM, and never looked back.