I'm working on a project for a client right now (yay! paying work!) that involves a subscriber interface, regular mailings (both e-mail and snailmail), database access (with additional conversion to .csv), use of templates for the mailings, and a few other interesting things.
I thought about doing this in an object oriented manner due mostly to what I perceived to be the major benefit of it: abstraction. I could write object methods that would do Thing A, while providing a consistent programming interface on the front end wherein I could change what the back end does without affecting the code that uses it overmuch, while additionally making the 'front end' code a bit simpler.
I posted to a list or two in order to garner some feedback from the more experienced people and proceeded to crack open the lovely OOPerl by D. Conway, and hacked together a working prototype of the initial data-access model to hold the subscriber data and allow me to access it in different ways. That now works fine. The trouble is what do I do next?
I mean, it's (relatively) easy enough to sort of do this in a linear fashion with functions as one would normally do. The problem comes from my lack of knowledge about how various OO systems work, whether or not I want to subclass other modules or merely use them in mine (IS-a vs HAS-a), and the lukewarm responses I've gotten to my queries in the posts I've made.
Now some people have indeed offered some constructive suggestions that really got me thinking about this but hoo-ee I may have bitten off more than I can chew trying to do this OO ..
Additionally I'm really having a problem generating a *complete vision* of how the thing should work, and I think this is severely hampering my ability to continue.
Do all midlevel perl gurus go thru this stage?
Don't waste your time trying to get it exactly right first time, you'll always miss something, and have to refactor and change later anyway.
Once you have your prototype and your goals you can start work on your documentation, from this you can trivially get your tests, which define your api, which defines how it will work from the outside which will make it clear how it should be structured inside.
Then you just keep on working on the documentation, tests, etc and it will be pretty clear how it should work and how to structure it.
There are some very useful tools to help with this - Class::Accessor, Class::DBI, Class::Attribute, etc.
Its probably worth looking around for some object oriented design books and spending some time learning how to design classes and relationships properly or at least in a structured way the same as you normalise your database - you do normalise your databases don't you?
