1. Welcome to the new MacRumors forums. See our announcement and read our FAQ

How can the "Class Object" NOT have Instance Variables?

Discussion in 'Mac Programming' started by Sandy Santra, Sep 4, 2008.

  1. macrumors 6502

    #1
    Totally confused here. Studying the Objective-C.pdf from Apple, and I read: "Class objects ... inherit from the classes above them in the hierarchy. But because they don’t have instance variables (only instances do), they inherit only methods."

    How can the "Class Object" or ("Factory Object")--which, as I understand it, is the "Master" object of a class used to create all its objects (i.e., is a "template")--be "cloned" to create Objects (or "Instances") with Instance Variables if the Class Object itself has no Instance Variables?

    :confused:
     
  2. Moderator

    robbieduncan

    Staff Member

    #2
    The class object is the recipe, but it is not the dish of food. The recipe does not have flavour, each instance of it (an actual dish of food) does.

    The same with Class objects and instances. The Class object encapsulates the recipe: it tells us about the Class, the name, the names of the messages it responds to.

    You may wish to read this

    p.s. sorry for the unusual analogy above: I'm watching a cooking program on TV :p
     
  3. macrumors 6502

    #3
    Very helpful analogy.

    So the Master Object (the "Class Object," or class's "template") has Methods but no Instance Variables, right? The Instance Variables only appear in the instances of the Class (after they are created).

    (Sorry, but the Wikipedia entry just leaves me more confused, since it introduces a third element--"interface"--when I'm still trying to understand how and when Instance Variables and Methods do what they do.)

     
  4. macrumors 68040

    lee1210

    #4
    Maybe some code will help...

    inherit.m:
    Code:
    #import <Foundation/Foundation.h>
    #import "TestChild.h"
    
    int main(int argc, char *argv[]) {
      NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
      TestChild *myChild = [[TestChild alloc] init];
      [myChild setX:6];
      [myChild setY:7];
      int test = [myChild x] + [myChild y];
      NSLog(@"The result was: %d\n",test);
      int test2 = [myChild XplusY];
      NSLog(@"The second result was: %d\n",test2);
      [pool release];
      return 0;
    }
    
    TestChild.h:
    Code:
    #import "TestParent.h"
    
    @interface TestChild : TestParent {
      int y;
    }
    -(int) y;
    -(void) setY:(int) setter;
    -(int) XplusY;
    @end
    
    TestChild.m:
    Code:
    #import "TestChild.h"
    
    @implementation TestChild 
    -(int) y {
      return y;
    }
    -(void) setY:(int) setter {
      y=setter;
    }
    
    -(int) XplusY {
      return x + y;
    }
    @end
    
    TestParent.h:
    Code:
    @interface TestParent : NSObject {
      int x;
    }
    -(int) x;
    -(void) setX:(int) setter;
    @end
    
    TestParent.m:
    Code:
    #import "TestParent.h"
    
    @implementation TestParent 
    -(int) x {
      return x;
    }
    -(void) setX:(int) setter {
      x=setter;
    }
    @end
    
    The fields from the parent class are available in the child. The document you were reading simply means that there are no values stored at the class level. This is contrary to some other languages that allow static variables in a class, so every instance has access to the same, class-wide variable.

    As you can see from the example, you can access the parents methods, as well as the fields in the parent, from the child. However, if you had multiple TestChild objects, their values for x from TestParent would be independent of one another.

    Don't worry about interfaces yet, but briefly they define a group of methods that institute some piece of functionality. This allows for a particular method to interact with a wide variety of objects through this interface, without these objects being of a similar variety.

    -Lee
     
  5. Moderator

    robbieduncan

    Staff Member

    #5
    Yes, basically.
     
  6. macrumors 6502

    #6
    Is the initial section (int main(int argc, char *argv[])) for creating the Class Object?
     
  7. macrumors 68040

    lee1210

    #7
    The initial section was just "testing" the class. I've annotated it a bit to try to clarify, but you may want to just skip it for now.

    Code:
      TestChild *myChild = [[TestChild alloc] init]; //Allocate a child object
      [myChild setX:6]; //setX is a method inherited from TestParent
      [myChild setY:7]; //setY is defined in TestChild
      int test = [myChild x] + [myChild y]; //x is a method inherited from TestParent, y is a method defined in TestChild
      NSLog(@"The result was: %d\n",test);
      int test2 = [myChild XplusY]; //XplusY is a method defined in TestChild, which uses properties defined in TestParent and TestChild
      NSLog(@"The second result was: %d\n",test2);
    
    What I was trying to demonstrate is that the properties themselves get passed down, but the current values are specific to one instance of the class (normally called an object), not shared amongst all instances.

    I'll probably butcher this, but in the soup recipe analogy, x would be part of the recipe, such as the soup containing carrots. Until you are actually making the soup, which specific carrots are to be used is unknown.

    -Lee
     

Share This Page