3 ms·

deleting a field ... never going to happen This is true for ANY class you release. I'm not even talking about a service API: if you published a class, and it g

• ed_blackburn 11y ago
  Depends. Things are rarely in absolutes :) If you serialise / deserialise you are probably coupled to an underlying type. Modify it instead of extending it and you have pain. If you parse the raw message, or serialise into a hash, or dynamic type then you have one place to make amends (your parser). Taking things further you can version your messages and map them to versions of parsers, as such you'd never violate OCP (or at least simply mitigate). Granted all of which is additional complexity compared to your stereotypical ball of mud / monolith that'll let you refactor field name changes etc to your hearts content. Obviously ball of mud approach has draw backs too...
• iofj 11y ago
  I always found getters and setters very helpful for this case. In C++ and in Java. Doubly so in Java because the following works: 1) field is no longer important, gets replaced 2) write a getter that still gets the value of it, but delete the field itself. --- this is where it stops for C++ 3) use the "inline function" refactoring on your entire codebase Done/done. You don't even have to rewrite the tests, in fact it might be better not to. (Of course getters and setters are somewhat verbose in most cases. Object pascal has the perfect solution though)