Henry Ford, founder of the Ford Motor Company in 1903, had a great philosophy. Get the laziest man to do a job and he’ll find the quickest way to do it. It turns the negativity of laziness on it’s head and turns it into something positive.
Laziness is not a bad thing in Software Development either, it turns out. I say this because like most people, I am lazy. I don’t like to write excessive code and I don’t like too much of a configuration overhead in my frameworks. It slows my creative process. That’s why I am an advocate of Convention over Configuration.
I discovered the concept of convention over configuration while exploring Ruby, until recently a rather obscure dynamic scripting language from Japan, and it’s increasingly popular Rails web application framework based on the Model View Controller (MVC) architecture. Relying on convention in Rails means adhering to naming conventions for Tables, Class Names, Methods and Class File locations, etc, in my Model, Views and Controllers. The convention dictates that classes are capitalized with no hyphens or underscores, e.g. BlogArticle and that the associated database table will be blog_articles. Convention also dictates that the class definition will be stored in app/models/blog_article.rb.
If I define a model class BlogArticle, Rails will map it dynamically to the blog_articles table in my database using ActiveRecord, an object-relational mapping layer. In fact, I can define an empty class that inherits from ActiveRecord’s Base class and dynamically have access to all fields in the table and be provided with getters and setters. I can then update my database schema without modifying my classes and without the need for a rebuild. I can even add validation into my classes, enforcing referential integrity and cardinality as well as valid value ranges for my class attributes.
For example:
has_many :comments
has_and_belongs_to_many :users
validates_length_of :title, :maximum => 200
end
What! - no attributes, no getter and setter methods? Trust me, they are there - you just cannot see them; they only exist at run-time. Bottom line? No XML and much less code. I get to be intuitive and Rails and Ruby read my mind. Well, not quite, but it sometimes feels that way. I don’t have to tell Rails how to conduct it’s business, it can work things out for itself. In contrast, some competing Java frameworks like Struts require so much hand holding and have to be told what to do all the time. Anecdotal evidence suggests that without this overhead (as well as other dynamic aspects of Ruby) applications developed using Ruby on Rails are completed with a fraction of the code. See http://www.relevancellc.com/blogs/?p=31 for a very good discussion on this. See Sails for a relatively new Java framework that leans heavily on Convention over Configuration.
Does that mean everyone is going to abandon configuration in favour of convention? Well, no. Even in Rails you can override the convention. People are creatures of habit and many will have a mistrust of a framework that encourages you not to define all your attributes and methods explicitly. Some people prefer to have somewhere to look to find out how everything hangs together, instead of working it out for themselves. Some people may even still advocate Hungarian Notation.
However, I would argue that less configuration and less code means fewer mistakes and even more agile development. Most developers will not care about naming conventions if they can meet their deadlines more often. If I can add a column to a table and have my application automatically handle the new column / attribute in the Model and the View, I can get back to my customers faster and have a more rapid iterative process between customer and developer. This ultimately leads to faster project delivery and an improved bottom line.
– Larkin Cunningham
Technorati Tags: Convention over Configuration, Ruby on Rails
0 Responses to “Convention over Configuration”