Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

WebDragon (1204)

WebDragon
  (email not shown publicly)
http://www.webdragon.net/

Macintosh owner/user since 1987
Perl hacker since 2000
Linux (Redhat/Fedora) user since 2001

Journal of WebDragon (1204)

Wednesday January 19, 2005
05:51 PM

OOPerl does my head in

[ #22795 ]

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?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The first thing you need to do is work out your goals, then put together a simple prototype.

    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

    --

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;
  • I've had issues like this as long as I've been programming (perl for 5 years, c++ for 4ish), and for myself at least, these are design and implementation issues and not really language or OO issues. I'm a slow learner, so things seem to finally be jelling for me. I recently purchased the GoF, (gang of four), book on Design Patterns [barnesandnoble.com], and it answered a lot of questions I've had for years about certain code design aspects, especially relating to GUI code design, but I think it also applies more generally. N