Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re: Seeking advice for OO-related strategy

by mstone (Deacon)
on Mar 05, 2005 at 22:44 UTC ( [id://436967]=note: print w/replies, xml ) Need Help??


in reply to Seeking advice for OO-related strategy

Any alternative suggestion? How is this kind of things generally done?

It's usually cleaner to demote the object's data to a separate class owned by the parent object, or even just to a single data structure owned by the parent object:

Instead of this:

package Parent_object; sub new { my $O = bless {}, shift; $O->{'attribute-1'} = "value 1"; $O->{'attribute-2'} = "value 2"; $O->{'attribute-3'} = "value 3"; [...] return ($O); }

do this:

package Parent_object; sub new { my $O = bless {}, shift; $O->{'data'} = _fill_attributes (@_); return ($O); } sub _fill_attributes { my $result = {}; $result->{'attribute-1'} = $_[0]; $result->{'attribute-2'} = $_[1]; $result->{'attribute-3'} = $_[2]; [....] return ($result); }

By demoting the data, you get rid of the circular dependency between the parent object and the user-supplied child function. The child function doesn't need to know anything at all about the parent object, it only needs to know the data object, or hash, or whatever. Instead of calling your child functions like so:

package Parent_object; [...] sub do_something { my $O = shift; my $f = $O->{'sub-function-for-this-case'}; $f->($O); return ([whatever]); }

You can just pass the data:

package Parent_object; [...] sub do_something { my $O = shift; my $f = $O->{'sub-function-for-this-case'}; $f->($O->{'data'}); return ([whatever]); }

It may not look like that big a change, but it gets rid of chicken-and-the-egg problems that can drive you absolutely nuts at design time.

Replies are listed 'Best First'.
Re^2: Seeking advice for OO-related strategy
by blazar (Canon) on Mar 08, 2005 at 15:29 UTC
    It's usually cleaner to demote the object's data to a separate class owned by the parent object, or even just to a single data structure owned by the parent object:
    Thank you for being so kind and take the time to answer my question. I'll take your advice into account, but still I fail to see how it can be related, if not marginally, to what I was asking...
    Instead of this:
    <SNIP>
    do this:
    package Parent_object; sub new { my $O = bless {}, shift; $O->{'data'} = _fill_attributes (@_); return ($O); } sub _fill_attributes { my $result = {}; $result->{'attribute-1'} = $_[0]; $result->{'attribute-2'} = $_[1]; $result->{'attribute-3'} = $_[2]; [....] return ($result); }
    I see what you mean, but...
    By demoting the data, you get rid of the circular dependency between the parent object and the user-supplied child function. The child function doesn't need to know anything at all about the parent object, it only needs to know the data object, or hash, or whatever.
    OTOH Tanktalus' solution with a closure is just as fine in avoiding that kind of "circular dependency" and is more close to "the way I want to do it". And it can still apply to the code you supplied, since it has to do with the subs that get passed in, not to what's in the objects that will use them. So the two issues are mostly orthogonal, IMHO...

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://436967]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-04-20 00:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found