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 PROTECTED] Sent: Friday, August 08, 2008 12:36 AM To: Lee, Frederick Cc: cocoa-dev@lists.apple.com 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
