in reply to OO Perl and Design Issues

Tye already mentioned 'demoting' the data from the table.. giving the class a single attribute (a hash) that holds all the tuples from that table instead of trying to make every key-value tuple from the table a full-fledged attribute. I agree with that suggestion, and what follows is a discussion of why I agree:

Good OOP tends to lean toward consistent interfaces.. every object in a class having exactly the same set of attributes and methods, with the instances only differing in their attribute values. That gives you the freedom to assume that any object from the same class will work exactly the same way, which in turn lets you write simpler client code (code that uses the object).

Polymorphism.. creating an object that inherits interfaces from more than one base class.. makes it easier to shuffle interfaces among several classes, but still keeps the interfaces themselves consistent. Every object in a polymorphic class still has the same set of methods and attributes, and it's still safe to assume that all objects from that class will work the same way.

You're asking how to put different interfaces on two objects from the same class. Yes, it's possible, but it tends to be a bad idea.

For one thing, changing interfaces on a per-object basis tends to make your client code insanely complicated. Instead of being able to write one-size-fits-all routines, you're forced to inspect each object you get to see what it can do. Then you have to work out the logical gymnastics necessary to reach the right handling routine for each permutation of attributes and methods. In the vocabulary I know, that's called 'floating' complexity up to the higher, more abstract parts of your program, instead of 'sinking' it into the lower, more concrete regions. Historical best practices suggest that it's better to go the opposite way.

For another thing, making objects that flexible tends to create a breeding ground for runtime errors that are a bitch to find and fix. Typos become especially nasty, because there's no reason for the object to think you don't want one attribute named 'thing1' and another named 'thing 1'. Likewise, it becomes easy to break your code by changing it in one place, but not propagating the same change to everywhere else that it might be necessary. And since your client code has to inspect the object a lot, you end up with more places to search.

And since you did specify design issues, those are things you should probably keep in mind. ;-)

Replies are listed 'Best First'.
Re: Re: OO Perl and Design Issues
by jonjacobmoon (Pilgrim) on Jan 02, 2002 at 04:28 UTC
    Maybe I need to think about this deeper (in fact I am sure I do, you always do), but I didn't mean to suggest that I wanted two interfaces. When I said that the data may come from the table or it may come from input, I meant that it was arbitrary not distinct. So that, I want it to be generic such that it is one interface able to handle any kind of data. Thus, the constuctor is set to handle an inputed hash. That hash is checked against a "permitted" hash which makes sure that no extra hash values are added to the object. The permitted hash does much of what you suggest. It grabs the columns from the table which are allowable. I simply put this in a seperate private method which I figured would make it easier to maintain. I think this in part addresses Tye' +s concerns which I agree are something to be careful of. Here is my current constructor: sub new { my ($caller, $args) = @_; my %memberData; my $class = ref($caller) || $caller; # grab the fields that are allowed to be member data $memberData{'_permitted'} = &_permitted(); for (keys %$args) { if ($memberData{'_permitted'}->{$_}) { $memberData{$_} = $args->{$_}; } } $memberData{'errors'} = 0; my $self= bless { %memberData }, $class; # $self->error now contains errors, check before proceeding..... $self->_validate(); return $self; } Does this take care of those issues or am I way off base? As I said, I have made these classes before but usually much more straight-forward. This time I want to try and the class so that I have the handy OO interface with a class that takes the data as a parameter because the member data fields will be dynamic (or at least I want to be prepared if they are).

      I think I see what you're getting at. Personally, I'd write the constructor like so:

      package Base_class; ## new (args:hashref) : Object_ref # # create a new object, then initialize it from class-specific # defaults and/or argument values. # sub new { my $O = bless {}, shift; my $args = shift; my $defaults = $O->_defaults; ## iterate over the keys in %$defaults, because those are all ## we really care about: for $k (keys %$defaults) { $O->{ $k } = (defined $args->{$k}) ? $args->{ $k } : $defaults->{ $k }; } return ($O); } package Subclass_1; @ISA = qw( Base_class ); ## _defaults (nil) : hashref # # return a hash of default values for objects of this class # sub _defaults { ## this is basically a static variable for the class. i ## define such things at runtime, but that's just a personal ## taste. if ( ! defined $DEFAULTS ) { $DEFAULTS = { 'attr1' => 'val1', 'attr2' => 'val2', 'attr3' => 'val3', }; } return ($DEFAULTS); }

      That gives you the freedom to create as many subclasses as you want, each with its own signature of attributes. Each subclass will only accept values from its own signature, and every object will be fully initialized to its own signature by the time the ref leaves new().