OO design.

lanta has asked for the wisdom of the Perl Monks concerning the following question:

I'm working to design an application using OO, this is the first time I'm doing this so any advice y'all can give is very much appreciated.

Background:

I have an entity( one among many ) let's call "Person" and I have many things I need to do with/to this entity, for instance
1. I need to fetch a list of "People" from the database and return to the user
2. Add a "Person" to the database.
3. Delete a "Person" in the database.

My approach is a file/class containing one operation(fetch, add, delete ). and a file/class which uses all these files/classes.
so I would have the top level class like so

#####################

Package Person

sub new {
        my $proto = shift;
        my $class = ref($proto) || $proto;
        my $self  = {};
        $self->{FETCH} = Fetch->new();
        $self->{ADD} = Add->new();

        bless ($self, $class);
        return $self;
}

sub fetch { 
   my $self = shift; 
   return $self->{FETCH};
}

sub add { 
   my $self = shift; 
   return $self->{ADD};
}

1;

#####################
and the underlying classes will look like so..

#####################

Package Fetch

sub new {
        my $proto = shift;
        my $class = ref($proto) || $proto;
        my $self  = {};
        $self->{FIELDS}  = [];
        $self->{FILTERS}  = {};
        $self->{RECORD_COUNT}  = 0;
        $self->{RECORD}  = [];
        $self->{DB_TYPE}  = 'oracle';

        $dbh = connect_db( 'login', 'password', 'dsn' );

        bless ($self, $class);
        return $self;

}

sub fields {
   .....
}

sub fetch_records {
   .....
}


#####################

and the usage of the package is as follows

#####################

use Person;

$per = new Person();

$fch = $per->fetch();

# Set Fields
$fch->fields( 'first_name', 
             'last_name',
             'middle_name' );

# Get Fields
print "The fileds being fetched are " . $fch->fields . "\n";

# Fetch People.
while( (@prsn) = @{$fch->fetch_records()} ) {
   print "@prsn\n";

}

print "No. of persons fetched are " . $fch->record_count();

#####################
[download]

My question is, is it ok for me to be placing each of these actions on the entity( adding person, fetching people ) etc in a class/file of it's own or should they all be in the same class/file. The reason I'm thinking I would like to split this into seperate classes is because I want the methods like record_count() specifically associated with the fetch object, since it has no relevance in the "Add person" context.
for instance, it all the actions were in the same class/file.
I would have a situation like

$per = new Person();

$ppl_fetched = $per->record_count();
[download]

where the record_count() method has meaning only in a "record fetching" scenario and not really with the whole Person object (which will have methods to add records, delete records etc ).
Sorry for the long post, Any and all help is much appreciated.

Comment on OO design. Select or Download Code

Replies are listed 'Best First'.
Re: OO design. by chromatic (Archbishop) on Jan 20, 2006 at 01:53 UTC
The idea of separating the data store behavior and the `Person` seems right to me, but having the `Person` object contain the storage objects seems backwards. I use the Class::StorageFactory approach myself. That is, there's a factory for loading and saving objects. You create, retrieve, and store objects via the factory. The objects themselves don't know anything about their storage. That does sometimes fail if you want autosave on destruction behavior for the objects, but there are ways around that too -- add a `DESTROY` hook to the objects that calls the factory appropriately.	[reply] [d/l] [select]
Re: OO design. by moot (Chaplain) on Jan 20, 2006 at 02:15 UTC
You might want to look into the various ORMs (Object Relational Models) such as Class::DBI, DBIx::Class and friends.	[reply]
Re: OO design. by srdst13 (Pilgrim) on Jan 20, 2006 at 10:52 UTC
In addition to Class::DBI, DBIx::Class, I would look at Rose::DB::Objects. I like the author's answer to your question--he recommends a Person class to hold a person. (One of the first things you'll notice when looking at the CPAN entry is that the documentation is quite extensive, detailed, and thoughtful and even includes a tutorial). The Person class, which inherits from Rose::DB::Object, contains methods to save itself, load itself (based on primary key) and has a "meta" object associated with it for introspection of things like column names and types from the database. However, a Person represents a person, not people. The author then recommends a second class, the Person::Manager class as he calls it, that inherits from Rose::DB::Object::Manager and has methods for complex searches, arbitrary joins, counting, deletes, etc. for dealing with Person(s). The concept was a bit foreign after coming from Class::DBI, which doesn't make as clear a distinction, but it now makes clear sense to me and is a clear answer to your question. I'm not sure where DBIx::Class stands right now on this issue, but before brewing another ORM, I agree that looking closely at what is available (if for no other reason than to learn the different approaches to the problem) is probably going to be fruitful. Sean	[reply]
Re: OO design. by ruoso (Curate) on Jan 20, 2006 at 17:46 UTC
$per = new Person(); $ppl_fetched = $per->record_count(); Well, you're making a common mistake. The "Person" object should represent one single person, not all the persons. OTOH, The "Person" class represents all the persons. This means you'll have "class methods" (usually called static methods) and "object methods" (usually called instance methods). For instance, the method record_count() should be called in the Person class itself, like: `my $ppl_fetched = Person->record_count();` [download] The same applies to add records (which means "new"), and to fetch records (which means, retrieve an already existing object). Theoritically, you would have something like: `# Create a new record... my $person = Person->new(\%some_data); # Retrieve an existing object... my $other_person = Person->find_by_id($person_id);` [download] And the access to the attributes (name, address etc) would be something like: `my $person = Person->find_by_id($person_id); my $name = $person->get_name(); my $addr = $person->get_addr();` [download] I hope this helps... daniel	[reply] [d/l] [select]
Re: OO design. by zombie_fred (Scribe) on Jan 20, 2006 at 20:27 UTC
If you haven't run across it already, go take a look at Damian Conway's "Object Oriented Perl". It's a bit dated (the publication date is 2000), but it has a reasonably good exposition on how OO Programming and Design can be implemented in Perl, and what the major pit-falls are. In addition the Ram Book('Perl Cookbook', Christianson & Torkington) has a chapter on Objects, Classes, and Ties that may also be helpful. -- zf	[reply]