I am sure there's a name for this anti-pattern somewhere; however I am not familiar enough with the anti-pattern literature to know it.
Consider the following scenario:
or0 is a member function in a class. For better or worse, it's heavily dependent on class member variables. Programmer A comes along and needs functionality like
or0 but rather than calling
or0, Programmer A copies and renames the entire class. I'm guessing that she doesn't call
or0 because, as I say, it's heavily dependent on member variables for its functionality. Or maybe she's a junior programmer and doesn't know how to call it from other code. So now we've got
c0 (c for copy). I can't completely fault Programmer A for this approach--we all get under tight deadlines and we hack code to get work done.
Several programmers maintain
or0 so it's now version
c0 is now version
cN. Unfortunately most of the programmers that maintained the class containing
or0 seemed to be completely unaware of
c0--which is one of the strongest arguments I can think of for the wisdom of the DRY principle. And there may also have been independent maintainance of the code in
c. Either way it appears that
c0 were maintained independent of each other. And, joy and happiness, an error is occurring in
cN that does not occur in
So I have a few questions:
1.) Is there a name for this anti-pattern? I've seen this happen so often I'd find it hard to believe this is not a named anti-pattern.
2.) I can see a few alternatives:
orN to take a parameter that specifies the values of all the member variables it needs. Then modify
cN to call
orN with all of the needed parameters passed in.
b.) Try to manually port fixes from
cN. (Mind you I don't want to do this but it is a realistic possibility.)
cN--again, yuck but I list it for sake of completeness.
d.) Try to figure out where
cN is broken and then repair it independently of
Alternative a seems like the best fix in the long term but I doubt the customer will let me implement it. Never time or money to fix things right but always time and money to repair the same problem 40 or 50 times, right?
Can anyone suggest other approaches I may not have considered?