[NCLUG] programming question

J. Paul Reed preed at sigkill.com
Sun Jul 1 02:04:28 MDT 2001


On Sat, 30 Jun 2001, mike cullerton wrote:

> this is a theoretical question. i'm wondering, is there a difference, in
> general, programmatically speaking, between having one large object, two
> disjoint objects or an object that extends another object.

I think Charles was right on when he said it depends on the language, and
also what exactly you're doing (which sounds stupid at first, but, in other
words, how are the object communicating with each other, how often, and how
do they make use of each others' facilities?).

What I was going to point out is an extension of Charles' point on the
language you use: if you consider C vs. C++ (and actually, most OO
languages), there is a speed difference between the two.

Those who push OO do so because the practice (done correctly) supports code
re-use, object-level testing, encapsulation, interfaces, and a host of
other goodies all very well. Put another way: OO languages make the
computer work a bit harder to the benefit of us human programmers, because
(now), the largest expense is a human's time, not a computer's.

So, I would say that you should write the classes in whatever way makes
the most logical sense for encapsulation, code re-use, the specific
application, and most importantly, you and your colleagues.

Because once you've taken the leap to do OO, your code is going to be a bit
slower anyway (whether it be C++, Java, or icky-disgusting 'OO' Perl)...
you might as well do the "right thing" (tm).

And, of course, you can always optimize your code at the class level later,
once you have built the thing and do some profiling on it.

I mean... if we wanted everything unbelievably fast, we'd write everything
in assembly... :-)

Later,
Paul
  ----------------------------------------------------------------------
  J. Paul Reed                preed at sigkill.com || web.sigkill.com/preed
  Homer no function beer well without.  -- H. Simpson, "The Joy of Sect"





More information about the NCLUG mailing list