report "Creating engine....";
    my ($engine) = new Framisdat::Engine();

    report "...stoking.";

    $engine->Stoke($engine_stoke_limit);

    report "...running.";

    while ($engine->Running())
    {
    }
[download]

This sounds like a plethora of issues; I'd like to summarise your comments ¹:

• You've not coded OO before.
• You're working on someone else's code
• Your task has changed unfavourably
• You have an iminent deadline.
• The program is suffering feature creep.
• Your anxious that maintaining OO might all be frustrating

Getting OO experience is tricky, ideally you'd have a mentor to guide you. merlyn has written a pretty good tutorial, as ever I'll mention Mr Conway's book, it rocks. Of course there is also perlmonk's own tutorials

OO is overwrought for small applications. This is Perl, there are ways around it (oh yes ;). With looming dead-lines (and bad code) good practice isn't high on the agenda, nor should it be. Hack my friend, hack like the wind. Learn OO in fullness later and fix poorly designed code during a lull.

For work issues, we need a well-measured response from someone with many years experience in development. My only real advice is pass the stress to your manager. (I bet you've done that already ;), but it is important to define the remit of your responsibility, to do your job well.

(1.) Because some folk seem to be wearing OO only blinkers, and I feel there are more answers to give than what OO is, and how it should be used. I can't answer all these points, so please add relevant stuff.

--

I really do feel your pain, but sometimes these things are actually done for a reason. This reason might not be immediately obvious to you, but it's still there. These are exactly the sort of things that should be in documentation so that you know the author did something consciously and for a reason rather than capriciously. Unfortunately, docs are frequently written so far after the fact of programming that the reasons for doing certain things get lost.

Of course, sometimes it's just a poorly designed system and there's no excuse to be made :-) (Calling use within a string eval is kind of odd...)

Another thing is this: Perl's OO implementation is quite low maintenance, so creating a subclass with refactored code (for instance, combining the three methods of Class A from your example) is extremely simple. If something's broke, you can fix it!

Chris
M-x auto-bs-mode

Every language has its own way of treating OO, and Perl is certainly no exception to having "its own way".

As you may or may not know, my day job pays me to write Powerbuilder code. Powerbuilder's "way" is the PFC, which is a service-based architecture. Because of that, the project I'm involved in has resulted in us creating a lot of objects whose only purpose is to do things for other objects (ie. a "sort service"'s purpose is to provide sorting capabilities for datawindows. A "time filter service" was created to provide information to any object that wants to know about time search criteria. etc, etc)

However, the project I'm working on is quite large (somewhere between 15,000-20,000 lines, 200+ stored procs, 20-25 table database, about 15-20 different windows, well over 100 classes we've written, etc). OO scales nicely though, and despite the fact that there is definitely a steep learning curve (steep in learning the PFC too), OO has taught what to me is a very natural way of thinking about The Way Things Work.

What am I getting at?

The point I'm trying to make is that you will probably find that with some patience and practice/experience, OO will scale well. Familiarize yourself with the way Perl does OO and try to think like it does (much like we're doing with PB and the PFC, which have lead us to think in terms of creating a service-based architecture). To this point, I haven't written my own OO code in Perl (I've used other's modules in "an OO way" though), but I still find that much of the way I think about OO in Powerbuilder is very applicable to Perl, certainly in terms of the way I can design classes and methods in a way that minimizes coupling and maximizes cohesion.

Give it a chance and you could very well find that this new way (for you) of thinking about things could open up a whole new way of solving problems. You might even like it. :)

For example: When you use DBI to access a database, you are actually using an object. Logging on to the server you use

DBI->Connect
[download]

You might be able to write scripts and use the objects in the toolset for specific tests.

I think that with time you will be able to understand what the creator of the toolset wanted. In the meantime, you can override methods or create your own inherited objects to test the toolset.