Question

I am taking my first stumbling steps in the Objective-C world together with a book on the subject. I have now come to the stage in which to internalize the concept of creating and using a custom class.

And as I guess that understanding these fundamental concepts and principles correctly is key to my future learning of Objective-C, I just wanted to check with you if have grasped the concepts somewhat correctly.

So when creating a custom class, I have understood that this is done in two separate files – the public class header file, and the class implementation file. And in order to internalize this concept, I have metaphorically understood this with a parallel to a “magician” doing its tricks in front of an audience.

The header file is somewhat like the poster outside the theatre where the magician performs. Before entering, we can all see what the magician looks like (the properties) and what tricks he (it’s mostly a “he”) can perform (the methods), and on what types of stuff he can make his magic tricks (type declaration). Thus from this “public” poster (the header file) of the magician, I can understand what kind of magic he can perform and what props he is using. Maybe there is also a mentioning of that this particular magician has learned some of his tricks from the great Houdini (the class heritage and Houdini thus being the superclass).

If I were allowed backstage, I would then be able to actually see how he is doing his tricks, that is, I would be able to look in the magicians implementation file.

Would this metaphor be somewhat along the lines of how you can understand the concept of a custom class?

However, I have not yet quite figured out how the concept of class methods and instance methods relates to this metaphor?

Could you say that instance methods belongs to a category of tricks that this particular “instance” of the magician is performing in this particular show, and the class methods would be the tricks that contemporary magicians can perform?
Thirdly, it is a bit confusing the way methods are using “types”. Some seem to be declared up front in the interface file, and some seem to just be “declared” on the fly within the methods?

To take an example using the “Magician” class, my understanding of the header file might look like this:

@interface Magician : NSHoudini

// Instance method that given a variable of type rat it will turn this into something of type rabit 

-   (rabit) FromRatToRabit: (rat) aRat;

@end 

And the implementation file might look like this:

#import “Magician.h”

@implementation Magician

rabit aRabit 
// rabit being the type and aRabit the variable


-   (rabit) FromRatToRabit:(rat)aRat;
{

// some magic code goes here which will take what’s in the aRat variable, of type rat
// and turn it into a form of type rabit and return it in the aRabit variable 

aRabit
}
@end

If above is correct I wonder why the aRat variable that you “feed” the method with is not declared? Or is the declaration considered done when you are using it in the method description?

Answer 1

It’s a great metaphor for understanding the divide between the public interface and the hidden implementation. But I think you might be getting a bit wrapped up in it and I do see two major misunderstandings – “Houdini” being the superclass and the class methods being “all tricks”.

The common textbook way to evaluate the sensibleness of an inheritance hierarchy is to evaluate whether a subclass instance “is a” superclass instance. This can get very abstract in reality but if, say, you’re designing the Magician’s Guild medical insurance benefits processing software or something, in that context a Magician “is a” something that’s definitely not a Houdini! Say they are all freelancers so every Magician “is a” 1099 Contractor (US tax form for self-employment income), or something like that. Another way to think of it would be to think Magician “is a” Stage Performer, which “is a” Entertainer, and so forth. Not that you always want to make software like this but it can help for learning the concept I suppose.

The second thing you said you were struggling with was how to think about class methods. Consider class methods behavior and information inherent to the type, and independent of any instance. Going back to the benefits software example, lets say all Magician guild members get a 401k (another US tax code thing, retirement account) with $X defined contribution per paycheck. Now assuming that’s not something that varies with seniority, this would be a good piece of information to keep at the class level. So, all the tricks a magician can perform would not be class methods – Magicians perform them, so they would be instance methods. Perhaps a list of banned tricks (for being too dangerous) could be a class method – it’s a rule inherent to being a Magician but is independent from any single magician.

Finally, to your third question about types, I can sort of guess at what you’re asking but am not sure. Say you have a method

- (void)myMethod:(id)myArgument
{
    NSLog(@"myArgument = %@",myArgument);
}

Then are you asking where myArgument is declared? It is declared right there in the method signature, where it’s a parameter to the method and you can refer to it in its scope of the method body (within the curly braces). Not sure if that’s what you meant by “on the fly” or not. I’m afraid you’ll have to provide some actual source code, not pseudocode, and point out specific places you’re wondering about.

And a couple of minor points on terminology, sorry this is getting so long – the term for “feeding” a value to a method is “passing” usually as a “parameter” or an “argument”. The method “description” is usually called a a method signature, or declaration, sometimes prototype I hear. And yes, please clarify what you’re talking about with types, type declarations, and so on, I’m not 100% clear on your questions there.

Hope this helps!