RE: Cocoa Dev Style: Using Class versus Object Methods
RE: Cocoa Dev Style: Using Class versus Object Methods
- Subject: RE: Cocoa Dev Style: Using Class versus Object Methods
- From: "Lee, Frederick" <email@hidden>
- Date: Fri, 8 Aug 2008 09:10:35 -0400
- Thread-topic: Cocoa Dev Style: Using Class versus Object Methods
Thanks to all for the basic insight.
Although I'm well aware of the benefits of OOP, there comes a time (for
many programmers)
to do some introspection.
That is, when to write/use procedural and object code.
I've been following ObjC examples and have programmed accordingly;
making objects
everywhere.
For example, using objects to develop the controllers within a MVC
paradigm; etc.
As you know, ObjC/C is a very rich environment; particularly with the
many frameworks
available. One can use simple C, and procedural/object routines.
The concern is to over-rely (over-engineer) code with objects when a
simple class (procedure)
is only needed. I'm becoming overtly dependent on Cocoa Objects and am
waiting for
the day <when?> an ObjC/Cocoa interface to the Address Book is available
(ditto elsewhere).
So I'm at the point where I need to introspect, to avoid
over-engineering a design without
sacrificing the value of objects.
The simple use of classes to compartmentalize procedural-specific code
is elegant; but not
a cure-all. It's when to use that approach vs creating objects, is what
I was after.
And of course, the foundation knowledge of how all this flows, in the
scheme of things.
Ric.
-----Original Message-----
From: Graham Cox [mailto:email@hidden]
Sent: Friday, August 08, 2008 12:36 AM
To: Lee, Frederick
Cc: email@hidden
Subject: Re: Cocoa Dev Style: Using Class versus Object Methods
On 8 Aug 2008, at 3:08 am, Lee, Frederick wrote:
> Greetings:
>
> I just came across a NSObject subclass written by someone, that
> contains a couple of date/Time-processing methods (stringToDate,
> visa-versa).
>
> The methods were all class-level methods (+) vs (-); and hence, didn't
> require the familiar alloc & init instantiation methods.
>
>
>
> I've been writing NSObjects via instantiation (requiring alloc & init)
> that I use to model business logic (packing XML data vectors, etc.)
> and
> hold a lot of common methods to use.
>
>
>
> I can see a project using class methods instead of instantiated
> methods;
> and hence, avoid the alloc/init memory hassles.
>
>
>
> My question (which is ELEMENTARY), is....
>
> 1) why use instantiated objects versus classes (via class
> methods)?\
Because you might need more than one of something.
> 2) Are classes stored in the stack & instatiated objects on the
> heap?
They are all on the heap. Classes are in fact object instances
themselves (though I wouldn't dwell on this, judging by your question
this is probably a bit advanced).
Seems to me that your basic understanding of OOP needs a few gaps
filling in. If you don't really "get" why object instances exist
you've probably missed one of the most fundamental points of OOP.
Maybe if you never need more than one example of any "thing" while
exploring programming you'll probably manage with class methods only,
but in reality, class methods are a convenience for some situations
rather than the usual way to get things done. The point of an object
instance is that it carries some data that is unique to that object as
well as providing a set of methods for operating on that data. By
contrast, a class's data (if it has any) is common to all instances of
that class.
To illustrate the difference, consider an example from the real world.
A class 'cat' exists which represents the species. Instances of cat
could be 'Tom', 'Dick' and 'Harry', all of which are particular
examples of cats. Since all cats have four legs, the class 'cat' could
implement +numberOfLegs to always return 4 - that data is the same for
all cats. But each cat could have different colours, so you'd have an
instance method -colour that might return black for Tom, ginger for
Dick and grey for Harry. You couldn't get away with a class method
+colour because not all cats are the same colour - you need an
instance to store each different colour.
Sometimes you might use a class that only has class methods to provide
some general-purpose functionality, such as the date/time methods you
mention. There is little difference between doing that and just having
some ordinary functions that do the same job, but once you get into
the object way of thinking, it's common to do this to keep code
manageable, consistent, flexible and future-proofed and so on. Classes
that only have class methods are pretty unusual though, so I doubt
you'll come across them too often.
You could write a project using only class methods - in fact that's
what everyone did, before OOP was invented. It's called procedural
programming. However, for the (very minor) "memory hassles" of alloc/
init, you are talking about throwing away nearly all of the baby to
get rid of a tiny bit of bathwater.
hth,
Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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