Re: Be grateful for Perl OO

[Steve_p]

The problem does not seem to be that Perl is better, it just seems like your system is in a serious need for refactoring. Here we go!

Step 1 - get a parent class for A and B. If they have the same interface in the code, inforce it and make your life easier. Based one the code, then, SomeFlag and SomeValue become irrelevant, so....

for (int i=0; i < SomeValue; i++)
{
    Class_P *p; //parent class

    int SomeID;

    p = (Class_p)* some_param;
    SomeID = p->getID;

Step 2 - Eliminating the switch...case. Many times, a case statement indicates some problems with the abstraction. So, lets create a new class called SystemCase for our purposes. It will be abstract with a class method called getInstance. Each individual case will be its own object. Since I can't beleive that these cases are only relevant in this chunk of code, this should help elsewhere. Since all of this is decided by the getID() method of p, there are some additional refactorings gained later...

class SystemCase{
    public:
        SystemCase getInstance(Class_P *p){
            switch(p->getID()){
                case FIRST_CASE:
                    return FirstCase(p);
                ...
        }
 
        virtual SomeArrayType runMethod();
};

class FirstCase{
    public:
       SomeArrayType runMethod(){ ... }
};

So, that takes the whole chunk of code to...

for (int i=0; i < SomeValue; i++)
{
    Class_P *p; //parent class

    int SomeID;

    p = (Class_p)* some_param;
    //SomeID = p->getID() isn't needed since we look at this in System
+Case
    SystemCase sc = SystemCase::getInstance(p); 
    SomeArray[i].value = sc.runMethod();
}

Eleven lines here, and the code is much more clear than before. You did a great job refactoring the code in Perl, but the same thing can be just as easily done in C++. As I mentioned above, if getID() is determining values to run elsewhere, the above refactoring should help out throughout your system.

[dragonchild]

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.

[RhetTbull]

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.

[dragonchild]

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.