[gameprogrammer] Re: "Mission Efficiency" - Blue Collar coding

> Well, less than what? I was told OO would allow software tools to be
> arranged in a heirarchical library, and used for many different apps.
> Except i'd been doing that for 20 years before meeting OO. I haven't seen
> every possible example, but most OO code i see has the A-level code
chopped
> into so many small pieces, and each piece embedded between layers of
> C-level stuff, that understanding it is like trying to rebuild a cow from
> so many hamburgers. And everything wants constructors, destructors, and
> other distractions which may be logically required by the language, but
> certainly not by the application.

OO, used correctly, can help manage complexity and promote code reuse.
Despite what they tell you in computer science courses, there is nothing
magical about inheritance or polymorphism.

Inheritance = automatically putting code for you in a derived class rather
than cutting and pasting it.
Polymorphism = an implicit if statement.  You could do the same thing by
putting an identifier in each class and just putting an if statement based
on that identifier.

Code reuse comes into play from inheritance because you don't need to cut
and paste code.  Code reuse from pohymorphism comes from that you can write
a code that takes a more general class and works as appropriate for the
actual class.  I.E. you don't have to write a big if / else chain  before
the function call.

I don't agree with grant that constructors and destructors are distractions.
If you don't need them nothing says you have to put them in.  On the
contrary, it is convenient to have a block of code that you know will be run
automatically before anything else.  It's not a catch-all and most of your
code will go into a once-per-game sort of initializer.  But it is useful.

OO, used incorrectly (as is often the case), makes code harder to follow.

The use of member variables means you have to understand the class to
understand the function.  Member variables are like global variables with a
lesser scope.  This is why it is important to document member variable
declarations, which many programmers don't do.

When classes are not encapsulated (public variables and functions with
side-effects) it's just a more complex format to write global functions and
use global variables.

Hidden polymorphism can make a program hard to follow.  One nasty example is
when a base class calls a member function that is polymorphic.  When tracing
you would expect the member function to be called but actually the derived
classes' member function is called.


> I seek not to rant ;)
>
> The cost of OO compared to, say, structured programming? First off, the
> boundaries are fuzzy, because on the street, comparing OO with !OO is
> typically to also compare C++ with C, and Windows with !Windows. But it's
a
> perfectly reasonable qn, so i'll try. But i'm really comparing OO and C++,
> and to an extent Windows, with some alternative language and o/s.
>
> One of the costs is that OO introduces a whole new category of errors,
> having to do with scope, range, inheritability etc., which, taken one at a
> time in a comp sci course, may make sense, but which, when dumped on the
> street with a real "blue collar" programming job, become just so many more
> ways to f*** up.

The programming language specific errors you describe are only made by
people learning the programming language.  You are arguing that since there
is more to learn, the cost of using a language goes up.  That is only true
for people learning the language.  After about a year's experience one (or
at least I) never made those kinds of errors again.  Since I now benefit
from those features, in some cases I can design modular systems that
prevents others from making errors and can reuse code that helps cut down on
cut and paste errors.  So in the long run it's a time-savings.

Other related posts: