in reply to (Ovid) Re: OO Perl and Design Issues
in thread OO Perl and Design Issues

This does indeed sound in part what I would like to do,
and I will look further into that.

However, I am having additional problems with trying to create
the object from a hash outside of the object.

Let me explain:

In addition to creating the object from the db I also would like
to create it from inputted parameters.  I am used to blessing 
a hash created inside the class, but this time I want to 
create the hash outside the class and pass it to the constructor.
If I do this, then I may not know exactly what the keys are
in the hash and in this way it can be generic.

Does that make a little more sense?  I know this is unusal. Maybe,
I shouldn't be doing it this way at all, but it seems a good
way to deal with a number of other issues I would have to handle 
such as dynamic databases (ie. columns changing in the input forms 
or in the databases).

[download]

Replies are listed 'Best First'.
(tye)Re: OO Perl and Design Issues
by tye (Sage) on Jan 01, 2002 at 03:37 UTC

    Although you can mix database fields and other parameters into a single hash, my first impression would be to avoid this and simply have an attribute in your object that contains a reference to the hash that contains the database fields.

    Though, exactly how to do this all depends on how you are getting the external hash into your constructor. The two common methods are "pass by value" and "pass by reference": 

    # Pass by value:
    $obj= My::Class->new( %hash );
    $obj= My::Class=>new( key=>"value", key2=>$value2 );
# vs. pass by reference:
    $obj= My::Class->new( \%hash );
    $obj= My::Class=>new( { key=>"value", key2=>$value2 } );

    [download]
    I prefer "pass by reference" because it leaves more room for API adjustments down the road, makes miscalling easier to detect, and few other reasons.

    So you could write a constructor something like this: 

    sub new {
    my( $class, $hashRef )= @_;
    my $self= bless $hashRef, $class;
    return $self;
}

    [download]
    but that could cause problems because it makes an object out of the calling code's hash directly. So, for example, 
        my %hash= ( key=>"value", key2=>$value2 );
    my $obj1= My::Class->new( \%hash );
    $hash{key}= "cheap";   # This changes $obj1!
    my $obj2= My::Class->new( \%hash );

    [download]
    would modify $obj1 and then make $obj2 an alias to $obj1 (so you'd really only have one object).

    So you'd want to copy the values (usually doing some validation, but it doesn't sound like you want to any of that): 

    sub new {
    my( $class, $hashRef )= @_;
    my $self= bless {%$hashRef}, $class;
    return $self;
}
# or
sub new {
    my( $class, $hashRef )= @_;
    my $self= bless {}, $class;
    @{$self}{keys %$hashRef}= values %$hashRef;
    return $self;
}
# or
sub new {
    my( $class, $hashRef )= @_;
    my $self= bless {}, $class;
    %$self= %$hashRef;
    return $self;
}
# etc.

    [download]
    To show just a couple of the ways to do it.

            - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]
      
(First, I made a similiar post already but it seems to have 
not made it to through the gates of the monastery.  I apologize
if it shows up twice.)

You make a very good point about the dangers here, and I 
will certainly implement your ideas.  However, I am a little
stumped how the constructors you listed would prevent the 
problem.

Can you elaborate?

For instance, how does:

 my $self= bless {%$hashRef}, $class;

protect the objects from being changed in the way you describe.

One thing I did was make %_permitted be a hash that is created
from the table data as well, so only those columns in the table
can be in the object and not anything extra, so that you if you
add to that hash randomly the hash will have the value but the
object will not allow it.  So, if it is not in the _permitted hash
then it is not part of the object.  Does that address the issue
in part, or did I misunderstand?

      [download]
[reply]
[d/l]
Re: Re: (Ovid) Re: OO Perl and Design Issues
by jonjacobmoon (Pilgrim) on Jan 01, 2002 at 03:37 UTC
    I apologize. I was being dumb. I knew I could do that. I started to doubt myself, and then two seconds after I made that post, I figured out that the reason it was not working was a stupid typo. My bad.
[reply]

In Section Seekers of Perl Wisdom