Re2: Be grateful for Perl OO

Wonderful reply, and exactly what I would do if I had the time, resources, and was able to convince my business owners that refactoring was in their best interests. I didn't even mention the worst part - this code is replicated between an C++ class and a C++ stand-alone. But, they're in the same application and there's no time budgeted to combine them. (The testing time alone to re-factor would be large.)

In addition, even if I could re-factor, I probably wouldn't create a common base class between ClassA and ClassB. From an IS-A perspective, they don't share a common ancestor. They just share a common interface. I'm not sure I'd want to create a fictional ancestor just to describe a common interface. (Though, that could just be the Perl in me talking. *grins*)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re2: Be grateful for Perl OO

Replies are listed 'Best First'.
Re: Re2: Be grateful for Perl OO by RhetTbull (Curate) on Jan 31, 2003 at 15:31 UTC
The testing time alone to re-factor would be large Ahh...a lesson for next time. If you have good unit tests from the start then you can refactor all you like; your unit tests will tell you if you've broken something. This is one of the tenets of Extreme Programming and for me was an "aha!" moment when I fully grok'd why it was so important.	[reply]
Re4: Be grateful for Perl OO by dragonchild (Archbishop) on Jan 31, 2003 at 15:45 UTC
Of course, if I had been here for 5 years (instead of 14 weeks, hired on as a maintenance programmer), I'd agree with you. Moral of the story - we don't get to pick and choose what crap we have to work with. We just get paid to work with it. And, because the relative effort involved in refactoring crappy Perl code is (magnitudes!) smaller than refactoring crappy C++ code, I am grateful for Perl OO. ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]