"Scott R. Godin" writes:
[snip disucssion of iheriting from a mailing class]
what would I like to do with the Subscriber?
o send them a welcome mailing
o snailmail - add them to tommorow's list of mailing labels along with a marker to the correct template
o e-mail - send them a greeting using the welcome template
o add them to a database
o retrieve them from a database
o based on certain criterion, send them monthly mailings of special events
o based on certain criterion, send them coupons on birthday or anniversary
But that doesn't mean you inherit from an address label printing class, an emailing class, a database class, a special events class and a birthday and anniversary class.
You simply use such classes to perform each task.
Now, some classes have APIs such that you have to subclass in order to use them (many XML parser classes for example) but emailing classes tend not to. When you want to send an email you create the email object populate the address, subject, body, etc. and call the method that send the email.
I suspect this is off topic, it's standard OO methodology - the same as in java, python, C++, <insert favourite OO language here>.
Only inherit when you have an ISA relationship. You don't seem to, you just want to use the API of a class - after all you could use a non-OO email module in the same way...
Are you planning on inheriting from DBI in order to get database functionality?
Indeed these are some of the very things that are 'bothering me' and are getting in the way of my "forming a complete mental picture of the result" so I can more easily break it down into tasks and just go code them.
I see what you're saying though.
Would you (folks) care to comment on ways I might be able to use my Subscriber class more effectively? Would you want to see the module's code itself? (I can easily post it to a website link so as to cut down the bandwidth of the message. In fact why don't I do that right now...)
http://www.webdragon.net/miscel/Subscriber-0.01.tar.gz
okay, that's the bare bones of it.
I guess I'm curious whether it even makes any sense to continue in an OO vein for this .. I had visions of being able to just
package Subscriber::Database;
our ($db, $user, $pass) = ("dbi:Path:here", "username", "password");package main; my $db = Subscriber::Database->new($subscriber_object);
$db->save() or die "Cannot save userdata : $!";
undef $db;
but perhaps I'm pipe-dreaming?
I mean, with an interface like this, I could have
$db->retrieve_match( column => "thing to match") and step thru the matches or $db->retrieve_all() to get everybody
my $href = $db->retrieve_emailers(); # loop thru the results # make a new Subscriber::Mailer object # fire off our monthly mailings from an HTML::Template or Text::Template
then retrieve the snailmailers, generate a list of labels, and a set of PDF docs personalized, and have 'em printed and mailed
I dunno, just trying to think about ways to abstract it so that I can change the way the underlying crap works without having to change the interface.
which SOUNDS a lot like OO to me, to be sure.
with a DBI object used this way I could change the underlying DBD easily enough, and export it to a .csv file, have a Setup method that stores the database/username/pass in a config file and insert them that way, so that it's reusable elsewhere without having to hard-code the data into the script itself...
things like this keep me awake at night. :-)
-- Scott R. Godin Laughing Dragon Services www.webdragon.net
