in reply to Re: Often Overlooked OO Programming Guidelines
in thread Often Overlooked OO Programming Guidelines

Delegation is better than inheiritance when the object doesn't want to export the full interface of the parent class. It is also useful when the object wants to change the behavior so much that it isn't a direct replacement. Also, it is helpful when the relationship needs to be dynamic, if the "parent" class is dynamic, or the referenced object needs change dynamically.

For example, many network client classes inheirit from IO::Socket::INET. This is convienent for both internal and external use. But it fixes the clients to only use IPv4 sockets. There are other types of sockets, like IO::Socket::INET6 and IO::Socket::SSL, that could be used if the inheiritance wasn't fixed.

Also, there is a need to change the socket but keep the same client object. Some protocols support negiotiating SSL over the existing TCP connection. The easiest way to support this is replace the reference to the IP socket with an SSL socket object.

  • Comment on Re: Re: Often Overlooked OO Programming Guidelines

Replies are listed 'Best First'.
Re: Re: Re: Often Overlooked OO Programming Guidelines
by scrottie (Scribe) on Dec 30, 2003 at 03:28 UTC
    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"

[reply]
Re^3: Often Overlooked OO Programming Guidelines
by Anonymous Monk on Mar 21, 2008 at 23:29 UTC
    Most of the times I prefer delegation. It is a useful technique, because it is really easy to reuse modules that way. But it depends on your programming style. I usually write small modules, which have one or two functions. I have for example a module Logging, which does exactly that: 'Logging'. I use delegation to build with them. For example I can put them in a facade, which does some more complex things.
    Inheritance I mostly use, when I want some method to be shared by all my objects.
[reply]

In Section Meditations