in reply to
Re: Re: Often Overlooked OO Programming Guidelines
in thread Often Overlooked OO Programming Guidelines
This is really a reply to the thread so far.
First, nice work Ovid. I'm jealous of anyone who can
write clear, simple examples - I haven't developed the
princepawn and iburrell - one objection I raised to
subclassing rather than delegating is the breakdown
of structure in the program. The best analogy I can
think of is databases. Databases with one large table
can't effectively be reported on - they have no structure.
No relation. No parts that exist seperate from each other.
You can always self-join - that is, join a table against
itself, but this quickly becomes pathological.
at the Perl Design Patterns Repository is my attempt to flesh out this
Obviously, this fits in very strongly with
Once you have structure, it must be navigated sanely,
but if you have no structure, why even try to navigate it?
Reporting is the database analogy. Reporting requires
one-to-many and many-to-many relationships and everything
required to create those - collectively known as
database normalization. With object oriented
code, you normally don't use the structure to report,
but rather model state.One hot dog might have multiple
topings. One table might order multiple hot dogs.
One table might have multiple seperate checks. They
might also have a pizza with multiple orders of the same
topping - cheese, perhaps. If I had a nickel for
every perl programmer that couldn't handle the slightist
bit of one-to-many or many-to-many in code, I'd be a rich
man. I've also suffered vast numbers of one-big-table
Microsoft Access databases in my life.
Database with exactly one table are a pathological case,
but databases with one table and all other tables joining
on only it are only a small improvement. Some
reporting can be done, but only explicitly supported things.
Some structure exists, but only where it is fancied
for the purpose the creator had in mind. Any other
reports, any other purpose, the structure is useless.
Data must be gleaned dispite the structure. Or
in spite of the lack of structure. Or something.
This is the GodObject - one large object that knows all, sees all, controls,
and only temporarily gives up control of the CPU to make
method calls that are sure to return back so it can
continue being in control. It is this desire to
centralize control that waylays effort or interest
in opening up to the wide
world of event handlers, listeners, state machines,
and so on and so forth - the bread and butter of the
object world. You can't write a good OO program with
centralized control, and you can't decentralize
control as long as you build large compound objects
and erase the distinction between different types
Someone in this thread used IO::Handle as an example
of something to subclass - that's a good example. The
rule of thumb is: subclass to create a more specific
kind of something that already exists, create a new
class to create a new kind of thing, and delegate to
create something which knows how to do things that
are defined in multiple seperate classes. IO::Handle's
existing and future subclasses are specialized versions
of IO::Handle: they read, write, flush, and do the
things that IO::Handle does, but in special situations,
and they do some related things that don't belong elsewhere.
You don't get IO::Handles that work on database sockets
that also know how to query the database, or if you do,
hopefully they create a $dbh instance, passing it
their socket, and delegate requests to that.
I've done this rant a hundred times. Can you tell? =)
One last bloody stab - re: Objects aren't always the way
to go, absolutely. Perl Design Patterns starts off on
a bender about you never know before hand that a program
will grow, require additions, modifications, not to mention
what it will need. You can't plan for the future, and
most of the time, you shouldn't even try. I think the
real art is two-fold: 1. Knowing how to start building
classes, delegations, aggregations onto something
procedural (or simplisticly OO) in such a way that the
program grows gracefully and scales. 2. Know top down
design, bottom up design, functional programming,
procedural programming, relational modeling, and so on.
Pick the right idiom. OO isn't for everything.
People in the Java camp tend to add too much structure
and thus obscure the problem and the solution they've
devised, not to mention oblivion to other idioms.
Using the wrong idiom is just as ineffective as using
the correct idiom badly.
A programmer who hasn't been exposed to all four of the imperative, functional,
objective, and logical programming styles has one or more conceptual blindspots.
It's like knowing how to boil but not fry. Programming is not a skill one
develops in five easy lessons.
-- Tom Christiansen in 34786.
jdporter - Fixed the markup error on "GodObject"