The Trouble with Deprecation

Comments

4 responses to “The Trouble with Deprecation”

1. 

   wirzi

   9. August 2007

   Deprecation might by useful if you change a widely used API
   and want to decouple dependency migration steps in the many
   different products using this API.
   Important: Remove the deprecated methods in the follow-up API
   version — after the grace period code shall be broken.

   But:
   Deprecating methods (in a local context) is in widespread use by those
   guys who are afraid of changes.
   I found them very often being afraid of their own code and “design”. (“Well,
   let’s do it quick here, we’ll fix it afterwards”).
   Aware that they do not know what happens if they change something.
   Suddenly realizing that the needed design improvements have been deferred
   every once in a while.
   If one finds himself in a situation that desperate I’d suggest:
   DEPRECATE your own idea of how software development is done
   and IMPROVE the design of your own working style at first.

   *angry*

   Reply
2. 

   felix

   13. August 2007

   Really vicious thing I just had to read was an @Deprecated on private field. The trouble with the industry is really, that thinking is not very common.

   Reply
3. 

   Chris Leishman

   5. December 2007

   I personally find @deprecated _very_ useful when working with a legacy code base (eg. one without any sensible test coverage). One of the key considerations in such situations is to keep all changes as small as possible. This is also one of the hardest and least common things to do – but it is critically important.

   For example, if I have a class with a terrible interface (eg. a ‘value’ object with setters, or an entity with no behaviour methods), then I want to change that interface. I can add tests around the object and I can add my new methods. But I _must not_ attempt to immediately remove the existing methods or ways of interacting with the object, because then I would have to change all the consumers of that interface – a potentially large, complex and risky change to a system with little immediate value.

   So now I have a interface with the new ‘correct’ methods, but also with a whole slew of legacy ‘cant-remove-these-yet’ methods. How do I make sure everyone else on the team knows which methods they shouldn’t be using anymore? Enter @deprecated.

   Reply
4. 

   felix

   6. December 2007

   @Chris
   I am still not convinced. I think the whole refactoring should be done in one go. You mention that deprecated tells the team how something has to be changed, i.e. someone else has to do it. This implies a not so collective code ownership. There is two things I am concerned about. First if you start doing a refactoring you are into the code, so you are the best person to do all of it. Everyone else will have to go through a “mental context switch” which takes a lot of time. Second it leaves the code in an “inconsistent” state. Old and new stuff exists in parallel.

   I completely agree with you, that the tool that should tell you about trouble in your codebase is the compiler. But ideally you should break the code and force people to fix it (one of the ideas of the java people was NOT to have compiler warnings as opposed to C++, which has plenty).

   I see the point for a provider of a library, that has independant clients. But even here it might be beneficial to dump old stuff. Just consider the jdk Vector-Hashtable-Enumerable mess, that is still with us.

   Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.