Doing It Right: BabyOp, Perl, and OOP?

I’m coding a new CGI application, tentatively entitled BabyOp. It is software to run a babysitting coop; I suppose it is a species of “social software.” The idea is to be able to track hours credits, schedule babysitting times, centralize contact information and other details about babysitting requirements.

I considered using something like Zope or Drupal for the application, but I’ve never liked developing exclusively through a web-interface and found myself having to do a fair bit of “actual” coding to get the results I wanted. I realize there is a command-line interface for Zope, but it’s really pretty limited. I had some plans a couple of years ago when I designed my wedding site in Zope to extend it to be more useful, but sadly never got around to it.

So I’m back in my comfort zone, perl. I’ve written a fair amount of unmanageable perl code, however, CoopOrder probably being a shining example (it was also my first perl program). I’ve certainly improved since then, and the fact that I’ve received several patches from others for randomplay suggests that my coding style is getting to a half-decent point.

I’d really like to get it right this time, though. One thing I’ve learned over the years is always to look for a module to do what you want before setting out to do it yourself, since chances are the module writer is a better coder than you (or at least, than me!). To that end, I’m using CGI::Application, HTML::Template, and DBIx::Abstract, among others. I’m also trying to keep things really granular and avoiding long subroutines. Certainly taking the HTML out of the perl code helps with that. I’m amazed at how often my code now just “works” on the first try, similar to esr’s story about his first look at Python (“Brace yourself: this code only took me about ninety minutes to write—and it worked correctly the first time I ran it.”)

I’m trying to figure out if it would be sensible to make this application more fully object oriented. Growing up in the ’70s and ’80s and having done a lot of database programming, I’ve always been unfortunately pathologically declarative. (My first major package was in Clipper—I was 13 years old). I find it a lot easier to modify a pre-existing object oriented package than to design my own.

But then again, does it really make sense to attempt an object-oriented design where there is really only one important “object” — in this case, the babysitting unit?

9 comments

  1. Steve Laniel Jan 28

    Objects don’t have to be just the real-world objects — in this case “babysitting units” — that you interact with. They can also be structures that only exist inside the program, which you want to keep in a consistent state. For instance, some C++ libraries provide wrappers around raw ints, so that the object will throw an exception if you overflow it (e.g., if you try to store 232+1 in a variable that’s only large enough to hold 232).

  2. Adam Rosi-Kessel Jan 28


    Objects don’t have to be just the real-world objects…

    I understand that, although at this point I’m hard-pressed to think of any ‘internal’ objects that I need. But that’s part of my problem–I’m just not object-oriented myself, so an object solution to a problem doesn’t leap to mind.

  3. GyrosGeier Jan 28

    Well, you’ve already gotten yourself a logo with a lens flare, so you may go all the way and implement it in Rexx.

  4. Benjamin Seidenberg Jan 28

    What about representing various clients as objects?
    How about the individual babysitters?

  5. Adam Rosi-Kessel Jan 28

    “Babysitting unit” is really the same thing as “individual babysitters.” The clients, in fact, are also other “babysitting units”–it’s a coop, so everyone is just babysitting each other’s babies. The only thing that happens when you babysit is that there is a transfer of hours from you to them. I suppose there could be different objects depending on whether the parent is functioning as a client or a babysitter, but at least as I’m thinking about it now, there wouldn’t be much by way of methods or variables in the client object, at least not that would be any different from the babysitter object. We just need to know who they are, and how many credits they have, and then be able to add or subtract appropriately.

  6. UG Jan 28

    As long as the roots are not severed, all is well. And all will be well in the garden.
    —Chauncey Gardner (1979)

  7. Steve Laniel Jan 28


    As long as the roots are not severed, all is well. And all will be well in the garden.
    —Chauncey Gardner (1979)

    I feel an immediate kinship with anyone who quotes Being There.

  8. Chung-chieh Shan Jan 28

    Let me quote Fred Brooks: “Show me your flowcharts and conceal
    your tables, and I shall continue to be mystified. Show me your tables,
    and I won’t usually need your flowcharts; it’ll be obvious.”

  9. Steve Stephens Jan 28

    Any sort of schedule for development? My wife just took over as secretary of her babysitting Coop.

    I’d be willing to beta test for you.

Leave a Reply

(Markdown Syntax Permitted)