I'm struggling to figure out how to refactor these large classes,

Okay, well you probably know this already, but a suite of automated tests really does help any sort of refactoring effort (OOP or not). You can split out functionality from one of the large blobs into smaller units, and then re-run the tests on the system to instantly get a pretty good idea if you've broken something.

Most grand doctrines on software development ultimately strike me as at least 50% snake oil [1] by weight, but test-oriented programming is one of the few that I'm completely sold on.

Caveat: when you've got lots of tests that check low-level routines, the tests become a kind of institutional weight on changing the way your primitives work. Any change in interfaces breaks your tests as well the code that uses what you've changed, so that's one more thing that needs attention. I don't see any thing to do about this but live with the pain: you really do need low-level tests, and perfectly designed interfaces that never need revision are a fantasy.

As for general advice on working with Objects: Favor "aggregation" over inheritence if you can -- inheritence is always tempting as a way to share common- code, but it causes problems when you get too fancy with it. Avoid inheritence chains deeper than one or two levels (possibly: reserve inheritence for fixing design errors, avoid using it in initial designs).

The notion that Objects are a "metaphor" doesn't really work: if you start off with a rule of thumb like "identify the nouns", you're likely to end up with something that's over-designed and that under-performs. My opinion (at the moment at least) is that it's best to just think about classes as bundles of routines that need access to the same data -- and it's perfectly okay to invent new abstractions that have no analog to some physical object (typically you need to come-up with bogo-nouns to convince people these are really "objects": "This is the Wangifier Handler Manager class").

I strongly suggest looking into the "Hash::Util" module (standard with perl 5.8.0), that provides "lock_keys" and "unlock_keys". You can use these with a hash-ref based object to lock down the existing field names, and help catch typos.

Try grepping your codebase for things like "$self->{". That will help find places where someone cheated and peeked at the object href directly. Replace those with actual accessors.

Off the top of my head, that's all I can think of... oh, maybe one more piece of advice: don't be a fanatic about pure-OOP. If it seems more natural to break out a standard operation as a proceedural module, there's no reason not to do that. And if you're working with a Real Relational Database (postgresql, oracle, etc) think about letting the database do some of the work (the class-to-table mapping popular with a lot of the ORM out there has it's problems -- though it probably does make for some quick prototyping).

[1] Or some other animal product.