Hi folks,

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 skill yet.

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. SelfJoingData at the Perl Design Patterns Repository is my attempt to flesh out this concept.

Obviously, this fits in very strongly with the LawOfDemeter. 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 of things.

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.

-scott

jdporter - Fixed the markup error on "GodObject"