Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Sandy Santra

macrumors 6502
Original poster
Feb 1, 2008
350
73
Brooklyn
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:
 

robbieduncan

Moderator emeritus
Jul 24, 2002
25,611
893
Harrogate
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
 

Sandy Santra

macrumors 6502
Original poster
Feb 1, 2008
350
73
Brooklyn
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.)

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
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
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
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
The code example(s) left me dizzy. That's weeks in the future along my present learning curve. The parent/child construct is a helpful one. I didn't understand what the initial section (first group) of code was for, though.

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
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.