Software DevelopmentThe use of "annotations" boosted our productivity in Golang
Everybody loves POJO's. Ever since Martin Fowler, Rebecca Parsons, and Josh MacKenzie coined the term back in 2000, the idea has taken the Java world by storm. Successful frameworks like Spring and Hibernate have centered on POJO's to make J2EE development a whole lot easier. Since then JDK 1.5 came along and brought us annotations. And now everybody's going crazy again. And by claiming to support POJO's old-skool tech is now trying to become fashionable again. Although I could not find an official definition of POJO, I think we can generalize from Martin Fowler's original definition that a POJO is not an EJB to a POJO is a Java object that is not tied to any specific framework, and therefore can be used by multiple frameworks in different situations and configurations. If you accept this definition, you'd have to agree this annotated POJO craze is silly. There's four problems with this, especially with the trend that a lot of these annotations are used to put configuration data in your code:
- You can't compile an annotated POJO without having the frameworks that include the annotations.
- The syntax is horrible when a lot of configuration data is put in. I'm not a big fan of XML configuration either but annotations just replace angle brackets with a whole lot of parentheses and curly braces.
- By putting configuration data in the class, you have to recompile your code to change the configuration.
- And finally, by doing this you can't have multiple configuration for the same class, e.g. map one class to multiple tables in the database.