Convention over configuration

Convention over configuration (also known as coding by convention) is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.

The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there's a class Sale in the model, the corresponding table in the database is called “sales” by default. It is only if one deviates from this convention, such as calling the table “products_sold”, that one needs to write code regarding these names.

When the convention implemented by the tool you are using matches your desired behavior, you enjoy the benefits without having to write configuration files. When your desired behavior deviates from the implemented convention, then you configure your desired behavior.

Motivation

Some frameworks need multiple configuration files, each with many settings. These provide information specific to each project, ranging from URLs to mappings between classes and database tables. A large number of configuration files with lots of parameters is often an indicator of an unnecessarily complex application design.^[1]

For example, early versions of the well-known Java persistence mapper Hibernate mapped entities and their fields to the database by describing these relationships in XML files. Most of this information could have been revealed by conventionally mapping class names to the identically named database tables and the fields to its columns, respectively. Later versions did away with the XML configuration file and instead employed these very conventions, deviations from which can be indicated through the use of Java annotations (see JavaBeans specification, linked below).

Usage

The Maven software tool auto-generated this directory structure for a Java project.

Many modern frameworks use a convention over configuration approach. A few such frameworks include: Spring,^[2] Ruby on Rails,^[3] EJB,^[4] JSF,^[5] Stripes, Kohana PHP, Grails,^[6] Grok, Zend Framework, Pylons, CakePHP, symfony, Maven, ASP.NET MVC, ColdFusion on Wheels, Web2py (MVC), Apache Wicket and the OutSystems Agile Platform.

The concept is older, however, and can be spotted even in the roots of Java libraries. For example, the JavaBean specification relies on it heavily. To quote the JavaBeans specification 1.01:^[7]

"As a general rule we don't want to invent an enormous java.beans.everything class that people have to inherit from. Instead we'd like the JavaBeans runtimes to provide default behaviour for 'normal' objects, but to allow objects to override a given piece of default behaviour by inheriting from some specific java.beans.something interface."

See also

• Comparison of web application frameworks

References

1. ^ C2 Wiki (2009-09-01). Too Many Parameters. C2 Wiki, 1 September 2009. Retrieved from http://c2.com/cgi/wiki?TooManyParameters.
2. ^ Chapter 13.11 describes the application in the context of spring model/view/controller http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html
3. ^ http://rubyonrails.org/, advertises the paradigm right from 'home'
4. ^ http://openejb.apache.org/3.0/transaction-annotations.html, transactional by default, http://openejb.apache.org/singleton-ejb.html, write locks by default
5. ^ "The design of JSF 2.0 is influenced by the philosophy of convention over configuration, popularized by Ruby on Rails."
6. ^ a description of configuration with the goal of convention http://grails.org/Unified+Configuration, and relationship to bean referencing from spring http://grails.org/doc/latest/guide/14.%20Grails%20and%20Spring.html
7. ^ Sun (24 July 1997). JavaBeans specification, section 1.4.

External links

• Detailed information on CoC