|Perl: the Markov chain saw|
O-O design, aggregation of objectsby wanna_code_perl (Pilgrim)
|on Nov 08, 2008 at 03:40 UTC||Need Help??|
wanna_code_perl has asked for the
wisdom of the Perl Monks concerning the following question:
Hello fellow monks,
I am hitting an embarrassingly basic stumbling block, getting confused between doing things the O-O way, and the "Perl" way. (Which, to my mind, can sometimes be two overlapping and sometimes conflicting goals!) In the end, I want something that is elegant, functional, and reusable.
I think what I'm really looking for here is a general Perl design pattern. For the purposes of this discussion, though, consider a "User" object in the system that has attributes "username", "real_name", and "email_address". There are also methods set_password, and check_password. (Implementation detail: Passwords are stored one-way encrypted, so these methods are necessary to do the crypt steps). As you might imagine, Users are stored in an SQL database. The above, I think is fine so far, yes?
Now, here is where I'm stumbling:
Who creates users? If I call User->new(), should that actually create a database entry?
Where does the search() function go? (For example, if I want to find all users with a particular email address). That doesn't seem like it should be a method of User to me. Should I have some kind of aggregation class like a UserSearch class?
When do I commit the User back to the database? Do I do this automatically whenever an attribute is updated, or through an explicit $user->write()? Does SQL code even belong in the User class? Or should the User instance be somehow passed to another specialized class that will do the actual storage functions?
Finally, can you point me to any good existing implementations of something similar?
Again, the User class is just an example. That being said, I want as much code re-use as possible, so if--for example--some of the DB and search mechanisms are better off put into a more generic class or library, suggestions there would be useful, as well.
A lot of questions, to be sure! Thanks for reading.