Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

At my job, in our core project, we have a Validation class that has been evolving with the years. And ee have an old project with an User class that uses an old version of the Valdiation class.

And we have to update some functionality that requires new validation methods. All those methods are implemented in our latest Validation class.

But the new Validation class isn't backwards compatible, so we can't just put the new one in place.

I thought that a good solution would be to upgrade all the code that references the Validation Class or making it backwards compatible but, obviously, both of them would take a lot of time.

Finally, it was decided that adding the latest version and calling it Validation2 works just fine, some methods use Valdiation and others Validation2. I think that will bring a lot of problems later, because you don't know when to use one or another as the names stop being meaningful.

What could be a better option to deal with this?

Also, the Validation class was the best example, but we have the same problem with a lot of bigger and more complicated classes and now we have a lot of "duplicated" classes. The language is PHP, but could happen in other languages too.

share|improve this question

3 Answers

up vote 3 down vote accepted

If the classes represent different concepts (in this case they are different agents that perform different tasks), they must have different names.

In your place I would give them different names that represent particularities of their natures. Not only a version number, but a meaningful name (you already pointed out why).

Besides, I would create a superclass and make this two validators to descend from it, a validator taxonomy comes to exist.

As time passes, I would work to replace the old validators by the new ones until the old one becomes unused, then I would remove it from the code.

share|improve this answer
up vote 0 down vote

If you're time constrained, then the solution you came up with sounds workable, albeit a bit kludgy. It sounds like you've created some technical debt and you'll eventually want to go back and clean it up.

Another option would be to create a "ValidationAdapter" class that handles translation from the old-style to new-style validation rules. Or it could just use both versions internally. The main benefit is that it keeps your main class cleaner; but it is also a short-term solution.

If the new Validaton class is supposed to supersede/replace the older one, then I'd say it's worth the time to refactor the code in question to make it work. Hopefully you've got your code under test; that makes it relatively easy to deal with. Otherwise you'll come back to the code later and kick yourself for making such a "mess."

Most languages have features to make it easier to deprecate older code. Doing so in your older validator might help you clean it out of your codebase and eventually get rid of it. I'm not sure the best practice for PHP off-hand, but I did find this stack overflow question.

share|improve this answer
Thanks, the answers in that question about throwing deprecated notices will help us with the future migration. – Pablo González Alba Jul 18 at 15:30
up vote 0 down vote

The better solution is to put unit tests on all of your classes, and keep all projects - even old projects - up to date.

If the effort of keeping a project up to date exceeds the value of that project, kill it.

Note that you will always be under pressure to just leave keeping things up to date. But that costs more in the long run - a lot more.

share|improve this answer
The project isn't internal. It was built and sold years ago. Now the costumer calls for a support upgrade. We aren't sure when customers would come back (if ever) so we can't mantain all projects just for the couple that will buy support. Nor we can upgrade everything for a small change (although this wasn't small and a complete upgrade could have been the best option). – Pablo González Alba Jul 18 at 15:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.