Re: Existence Based Polymorphism

On Wed, Jun 2, 2010 at 4:03 AM, Richard Fabian <[email protected]> wrote:
> I've been thinking about this a lot over the last few months, and come to
> think that if OOP was not "bad", then there wouldn't be so many "effective
> C++" or "C++ gotchas" like books out there. How many "pitfalls of procedural
> development" books have you seen?

I've also been thinking about this recently. Ignoring the specific
failings of C++, I'd say the biggest issue is that there seem to be a
couple of very common misconceptions.

The first is that a lot of people seem to implicitly think that
inheritance is the engine of reuse, so everything becomes an
"AbstractBaseObject" or some other nonsense, as though typing
colon-public-base-class-name somehow magically causes reusability to
rain down from the sky, washing half of your engineering work off into
some gutter. Obviously this doesn't work, but people stick with it
until you've got a 20-level hierarchy and nobody can remember what
level foo() was declared at and whether it is (or why it is) virtual.
At that point, things get worse, since the fact that nobody is clearly
reasoning about what the code really is causes people to treat it like
some sort of magic black box, invoking functions and setting
properties in specific "sacred" orders at preordained times, and
generally entrenching the details of the design so far into the
codebase that it's near-impossible to fix things later.

The second (and someone recently linked to some article or something
that also brought this up) is that people have this "the class should
reflect the thing we're modelling" notion stuck in their heads. Two
problems with this. First off, that's usually neither a clear nor
efficient interpretation of your concept into code. Second, it leads
to thinking of base classes as abstractions in a very human sense,
which is just *wrong* since ideas like "vehicle" and "four-seater" are
circles in a Venn-diagram, and *not at all* nodes in a graph (let
alone directed acyclic graph). Fine, a car is a ground vehicle which
is a vehicle. Where do you stick the engine object? Does it belong
anywhere in that hierarchy (what about bicycles)? Do you use multiple
inheritance (making things even worse once the hierarchy has gotten
deep)? At any rate, too many people blunder on through it without
recognizing the fundamental mismatch between what they want and what
their tool is capable of, making the mess bigger and bigger (and now
we've added hasGasTank next to gasTank in order to accommodate
Bicycle...) Etc.

The most effective use of OOP I've ever seen (or achieved myself) is
cases where objects are less "models of the real world" and more "Lego
blocks" - because *that* is how you get reusable code. They should,
IMO, be tiny little things designed to do one thing really well (the
best metric I've found for whether it's small enough is mode-type
properties - you should be down to no more than two bools or a small
enum) and be assembled together into bigger constructs on an ad-hoc
basis. So, for instance, a Button shouldn't have properties for
rendering or tab order or anything of the sort on it. It should simply
trap mouse events, update some simple state, and call its on_click
function. It should be something else's job to watch its state and
inject one or another visual description into the draw list. It should
be something else's job to figure out which control has keyboard
focus. At that point you don't have to lift a finger if your designer
wants buttons that have flashy spinny animated stuff on them - you
just say, "Design a flashy-spinny visual thing in place of the
text-label visual thing that's attached to it right now, it'll just
work" instead of the classic "let me type class FlashySpinnyButton :
public Button { ... } and get back to you" approach I've seen *far*
too many times.

Incidentally, I think I'm approaching the old structured-programming
style of reusability and something like Richard's existence-based
processing (which looks like an *excellent* way to stick small objects
into useful components) from another angle which, I think, says
something positive for the usefulness of both.

Cheers!
Phill
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com