Re: Classes and the Production of Objects
Re: Classes and the Production of Objects
- Subject: Re: Classes and the Production of Objects
- From: terry <email@hidden>
- Date: Sat, 10 Aug 2002 01:41:42 -0600
I'm going to take a shot at answer this, even though my Cocoa skills
aren't quite up to par yet. ;) (A lot of this is similar to Java/C++)
On Saturday, August 10, 2002, at 01:06 AM, Brendon Bruns wrote:
When you define a new class in a program, is an object created
immediately
and automatically from that declaration (such as at runtime) or does
the
class exist as raw code and need an instigator to make an object?
No, an object is only created when you specifically instantiate an
object.
For instance:
Let's say you have class "NSFoo". It's exactly that... class NSFoo.
To create an object you'd do something like:
NSFoo bar; //Object bar of class NSFoo
I'm not sure what you mean by "need an instigator", because the
instigator is you, the coder, by doing something such as the above
declaration of bar.
The class is a template for an object. Think of it as a blueprint.
You can have a blueprint of a house, but that doesn't mean you have a
house. It means you have instructions for a house.
In my "Learning Cocoa" book, it is stated that a class can be assigned
methods and possibly have have variables that are created for it.
I'm not sure if you *can* have class variables... can someone else
elaborate there?
I do know that class methods are specific to the class, they do not
extend to object, and object methods do not work with a class
declaration, even though they are defined in a class declaration. :)
I may be wrong about some of this, but this is how I understand it.
(corrections quite welcome. :)
For instance:
Let's extend the above class NSFoo.
If we did something like:
+ (NSFoo) doFoo
{
Do stuff to initialize your object here.
}
That's a class method. It could actually create the frame for your
object, and pass it back, much as +alloc does. This is a class method.
It might set up the memory for your object's instance variables.
That's mostly alloc's job, I think, but for this example, we'll assume
that doFoo sets up our object.
So to create an object in this example, we could do something like:
NSFoo bar = [NSFoo doFoo];
Note, that we have to specify the class name when passing messages that
instruct a class to look for a selector. This is an important
distinction.
Also, the "[NSFoo doFoo]" is a message... basically, "doFoo" is the
message that we are sending to the "NSFoo" *class*. This is NOT the
method that will be invoked, but NSFoo does look up the "doFoo" message
in it's "selector table" (Is that the correct terminology?) and sees
the "doFoo" method we defined. Message passing is a bit confusing for
new people at first... and it just barely clicked with me today, so if
you have trouble don't worry about it too much, you'll get it
eventually.
So in
relation to the question I stated above, does this mean that a class
can
exist without creating an object and in fact, it can do some work?
Yes, classes can exist, and in fact by nature *MUST* exist, and can
(have to) do work (to create an object, for instance... )
Note that method definitions that begin with a "+" are *class* methods,
while method definitions that begin with a "-" are object definitions.
Each type of definition is only acted upon by either a class, in the
case of "+" methods, and objects in the case of "-" methods.
In other words, classes can *not* (to my knowledge) act upon "-"
methods, and objects can *not* (to my knowledge) act upon "+" methods.
They're separate.
Or are
the methods there in place to tell the class to create an object?
Yes... having blueprints doesn't do much good if you don't create the
objects that they define. Remember that classes are like blueprints,
but more than that... they are sort of like blueprints for an object
AND the factory to create the object.
Their job [classes] is to define and create the object for you, but
your job is to tell them to create the object.
Finally, does an Instance refer to the Object that has been created by
the
Class and it is the chunk of code in memory that actually processes
data?
An instance is an object.
A class' job is specifically to create and deal with it's objects. It
doesn't deal with anything else. (AFAIK)
Back to the blueprint/factory idea:
A class, since it is a set of blueprints (for the most part) can't
really do much. The object is what interacts with things. Object
methods act on the object's instance variables.
Therefore, an Instance would be another name for an active Object in
existence?
What do you mean by "active object in existence"? The very fact that
you *have* an object means that it exists... but yes, an instance is an
object... or, more precisely, an object is an instance of the class
that defines it.
Thanks for any help! I have an annoying was of analyzing things too
much
and it gets me into trouble when I try to understand a new "language"
that
is not static and can exist in a multitude of forms.
Objective C seems to be *much* like Java and C++ in some respects.
Class methods exist in Java, and they behave pretty much the same
way... I *think* you can do something similar in C++, but I haven't
seen it much.
I hope this has helped...
Good luck.
If I've misinformed you with anything, I'm sure someone else on the
list will point it out in a more correct way. I'd like to know myself,
because I'm sure I don't understand it completely quite yet.
- Terry
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.