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 |