Kevin, I can't give definitive answers but I'll try.
I'm fascinated with the history of computers, so while I didn't
experience it I see where you're coming from.
Yes, we do have much more resources available now. I think you're
going to have to adjust to the fact that an identical app written in
any modern OOP is going to use more. The advantage is that OOP is much
more structured, and overall is easier for the developer in many ways.
It's more logical.
30%, however, is definitely too much if you're talking about a simple
learning app. I'm not qualified to even speculate where it's all
going, though.
Cutting corners is something you worry about if you're doing something
big. Think big title games (Halo, Sims) and bigger productive apps
(photoshop, final cut). They need everything they can squeez out.
Every app should be as clean as possible for general better code
production but it's by no means necessary for most people. However, in
subsequent releases of an app slimming the code can be nice,
especially when you can say your app is now faster.
The structure of the class hierarchy is such that most code can be
reused. The only classes you need to write are your controllers
usually. And they should be as long as you need. Period.
If you want to go back to the need to cut corners, something which
appeals to me personally, try iPhone development. You can still use
ObjC and Cocoa but you're limited, comparably to the olden days.
Good luck, Nate
On Jun 20, 2009, at 7:36 PM, syntonica <synton...@yahoo.com> wrote:
Hello All--
I am new to Cocoa (about 3 weeks now) and have not done much
programming since the halcyon days of 16K RAM. Finishing up the
main body of my program, I looked at what I have done and shivered.
I have implemented a delegate method for "textDidChange" to handle a
few things, including live updating the same field on a
NSTableView. Now, according to my informal measurements (watching
the CPU meter while typing furiously), my program eats up to 30% of
the 1GHz G4 CPU! That seems a little extreme just to type a few
words.
My questions are:
How can I tell how computationally expensive a class or method is?
I've never been this far from the metal. Is there a corpus
somewhere listing this, or do programmers just know these things
from their experience?
In the old days, we would cut corners and break rules to get better
performance or memory usage. The idea of "more" meant thousands of
dollars more. Now, resources for your average little application
seem to be limitless. So, do I just walk the straight and narrow
and let the Frameworks worry about these things for me?
Finally, on a side note and because this is my first OOP, just how
big should a class get? Just as a rule of thumb. I have 700 lines
and 50 methods in my MyDocument class and it seems positively
bloated to me. Is this normal? Or might I possibly have a bad
design? I only see a couple of lines that could be factored into
their own method and nothing that could really me moved into its own
class.
I know these are rather vague questions with amorphous answers, but
I am hoping somebody can shine some light or at least show me which
door I need to go through.
Thanks in advance to any and all who are able to reply.
Kevin
_______________________________________________
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/lipton_lover
%40mac.com
This email sent to lipton_lo...@mac.com
_______________________________________________
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 arch...@mail-archive.com
