Re: Noob question regarding Cocoa objects.
Re: Noob question regarding Cocoa objects.
- Subject: Re: Noob question regarding Cocoa objects.
- From: James Bucanek <email@hidden>
- Date: Tue, 28 Nov 2006 09:42:53 -0700
dan wrote on Monday, November 27, 2006:
>I'm learning objective-c with Cocoa coming from a Java background. Have
>some questions to make sure I'm on the right track.
>-------------------------------
>1-I'm thinking an objective-c object's init method is basically
>equivalent to a Java's class constructor?
>-------------------------------
>2-By calling init (To initialize an object) it reaches the top most
>object (NSObject) while executing all the init in the object tree?
>Let's say there's objects A through Z, and Z inherits from NSObject.
>So [a init] will call init inside B through NSObject?
>-------------------------------
>3-Guessing my own objects (That I created) does not have to have an
>"init" - but it could be labeled as "initWithParam", etc. But I would
>have to create a logic that calls the super class init?
Coming from a Java background, I wrestled with many of these same questions. Hopefully, this should clear things up:
There are no constructors/destructors in Objective-C.
I know, you're saying "but, but, but..." -- but it's true. Objective-C really has no _formal_ constructor/destructor syntax. There is nothing built into the language to handle initializing an object when it's created or deconstructing an object before it's deallocated.
All of the -init, -initWith..., -dealloc (-retain, -release, -autorelease, ...) are simply conventions which Objective-C programmers, and the Cocoa framework, follow. In nutshell:
You are responsible for constructing your object.
In other words, you have to do all of the work yourself. Which turns out not to be that much work, but you have to keep in mind that unlike C++ or Java, the compiler/run-time will not be automatically calling any super-constructors for you, or enforce any rules on how you do it.
When you create a constructor, it is your responsibility to call the super-constructor first, which is why you'll see this pattern repeated over and over again:
- (id)init
{
if ( (self=[super init]) != nil )
{
// your initialization goes here
}
return (self);
}
You can also call another init method in the same class, but in the end the appropriate super class' init method must be called first before you start initializing your object
- (id)initWithParam:(int)param
{
if ( (self=[self init]) != nil )
{
// [self init] did basic initialization
// do more initialization with param here
iVar = param;
...
The flip side of having to do all of this work yourself is that you get to bend the rules. One common pattern used in Objective-C is the "class cluster" where a constructor (the -init method) actually returns a different object than the one that was allocated. It can do this by changing 'self' -- something you definitely can't do using Java or C++:
- (id)initWithParamter:(NSString)param
{
if ([param someCondition])
{
[[self init] release]; // finish base initialization, then throw it away
self = [[MyClass factoryObject] retain];
}
...
Essentially, any constructor can be changed into a factory. Which also means that you should never write the following code:
id object = [SomeObject alloc];
[object init];
[object doSomething]; // wrong: object returned by -init might != object
>-------------------------------
>4-Working with objects I think of alloc and init. But some objects offer
>methods that does it for you? (Basically my last question with an example)
>
>Using NSString...
>NSString *string1 = [NSString stringWithString:@"this is a test"];
>
>Here stringWithString: actually fires off NSString init?
>-------------------------------
Think of these as factory methods. They typically create, initialize, and return a finished object (return [[[SomeClass alloc] init] autorelease]), but they might just as easily return a singleton or an object from a cache.
Both the alloc and stringWithString methods are *class* methods (think static methods in Java). These are methods that get sent to the class object itself, not an instance of that class. Their declarations begin with + not -, and are typically named after the kind of object they return.
And as others have written, get a good book on Objective-C. It helped me a lot.
--
James Bucanek
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden