EMF is a very powerful framework and with power comes…responsibility. You can achieve great things with a minimum of effort using EMF, but if something goes wrong, you can also spend hours trying to find out why. This blog post is part of a series on things you should do and things you should not do when using EMF. You can use the link to the series pilot to navigate to the start and the next link below to navigate to the next blog once it is published.
EMF Dos #3: Rename generated methods before changing them
First of all let me remind you about my previous blog post and why you should avoid changing generated getters and setters. If you intend to do it anyway, there is a preferred pattern to do so. Rename the generated getter/setter to getXGen or setXGen without using a rename refactoring. Leave the @generated annotation as is. Next, create a method with the original name and signature getX() or setX() respectively and add a @generated NOT annotation. In this method, you can implement your custom code while still calling getXGen and setXGen where appropriate. Alternatively you can achieve the same by using an extract method refactoring on the original getX() or setX() method body, extracting getXGen() or setXGen(). Anyway, if you follow this practice, the generated part will still be updated during code re-generation.
Stay tuned for more Dos and Don´ts in my next blog!