Human nature has a tendency to take things to extreme. A good day to day example is the Stock market and this behavior is rampant in other areas of life also. I feel we are doing the same thing with annotations. We are probably stretching it too far, much more than it warrants. Unfortunately I feel Spring is falling in the same trap. I do say that there are places where annotation makes complete sense, but I think there are places where annotation does not make sense and is introducing extra complexity in terms of readability and understanding. We are putting more burden on building complex mental models and moving things away from written artifacts, which was easier to understand. A lot of implicit understanding is not good for developers. Not all developers are intelligent. There are a lot of developers who do programming so that they can feed their family. They have no interest in understanding the complex programmatic models. EJB2.1 is a failure and still people struggle to do Hibernate the right way.
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, which has an example of Logger factory. Now I have to understand, who produced this logger factory and than I have to understand injection point and than somehow, how they are connected together. We might have an argument that we are depending on interface only, but again I am not sure if that is such a big advantage to introduce a complex programming model. There is an interesting statement in the above article in first part. I quote "Finally, Java EE 5 developers will likely feel that CDI is much more complex at first glance but will see that most of the complexity is well justified and can be ignored when not needed." This is the same argument we heard when EJB2.1 came. Of course, tool can come up to help in visualizing the relationship, but than I have to switch between my tool and code to see the things. It's worser than switching between XML and code.
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.
No comments:
Post a Comment