The gold rush to Annotation
Taking further my argument on annotation, I would like to divide the whole issue in two parts. One part where annotations makes sense and other part where annotation dos not make sense.
- Mapping stuff that is inherent to class
- Mapping stuff that is not inherent to class
Mapping stuff that is inherent to class
Here annotation shines. No doubt about it. Good examples are hibernate or JPA mapped classes, JAXB based mappings, Servlet mappings, Controller mappings in Spring. Here we are putting all information about a class at one place. The information sitting is XML was an integral part of this class. If one looks into a hibernate mapped class, the next question comes how it is related to my data model. The argument that goes against it is that, the class cannot be reused, which I find is more for the sake of argument. On the contrary I think these classes should be written with mapping, so their purpose and reason for existence is clear.
Mapping stuff that is not inherent to class
When the stuffs are not inherent to class, annotations are a bad choice. Those places are nicely handled at XML level. When I see the configuration XML in Spring, I know a lot about the application. Now with annotations, I have to hunt around to understand something. There is an article on CDI at Server Side
After EJB2.1, the Java world geared itself towards reducing the programming constructs. One of the major argument against EJB2.1, was lot of boiler plate code of no use. Spring did hit the sweet spot and became popular. But on the way, we forgot the need of a simple mental model. At this moment, I think we need another wave which reduces the mental model complexity or better to say which strives to bring both of programming simplicity and mental model simplicity. Not all are Einsteins in the world and Let's make it simpler but no simple. Scoring on all front will help better.
Post new comment