Generate or Handcraft?
One irritating thing I used to find in my early years of programming was the amount of time I spent on handcrafting details. Over the years, slowly but steadily, I have learned the art of meta-programming and I would say it is now the best tool in my programming arsenal. So what is meta-programming? It is programming using metadata. And what is metadata? It is data about data.
For example, databases have always provided metadata information in terms of dictionaries and meta tables. Database metadata include, information about the tables in the database, indices on tables, procedures that are available etc. Similarly you can have metadata about your application. Whenever I start hand-coding details, I try to extract the details in terms of metadata and write a framework that can interpret the metadata.
One of the main disadvantages in handcrafting details is that details change frequently forcing you to make changes to your programs to capture the changes. The more changes you make manually, the more bugs you introduce in the system. In my experience hand-coded details create the most number of bugs in the system. So, how do you get around this? The answer is metadata!! You externalize the details from your code to metadata. Then have an abstract
framework that can interpret the metadata. For this you can have a number of strategies like static code generation based on metadata or a more dynamic reflective framework that can interpret the metadata. This means the only place you introduce bugs is in the framework. A bug in the framework will be manifested in every single artefact of your system that uses the framework, which makes the bugs easier to find and fix.
J2EE introduced the art of meta-programming to the enterprise Java world. With deployment descriptors you externalize a huge amount of meta information from the code and you delegate the tasks of interpreting the meta information to the containers. This was further enhanced by the
introduction of great tools like XDoclet that used doclet based metadata to extract more details out of the code. Then came tools like Middlegen that generated your entity beans from the metadata in the database. If I look back to around four years ago on how I wrote entity beans and how I write them now, I would say it has been a quantum leap. This doesn't need to stop there. In my current project we used fastlane readers backed by stored procedures for bulk reads. All our fastlane readers are generated using a custom Ant task and Velocity based templates driven by metadata in the database. The next step would be to capture your domain logic in terms of metadata (you can even have a custom domain language) and drive your business components off that meta information. Less code you write, less bugs you have and more maintainable your system is.
Some of the advantages I have found on using meta-programming are,
- It is easy to find and fix bugs
- You spend less time with details
- Your system is more adaptable to changes
- You spend less time on repetitive and redundant tasks
- Your system is better designed as you spend more time in writing a robust framework and less time with the details