Definition of ‘Convention over Configuration’

The words ‘Convention over Configuration’ are often bandied about in the programming world these days and I suspect that the idea has largely grown out of some of the complexities and muddles that have been created with XML configuration files.

As a ‘Convention over Configuration’ example, take the wine search scenario that I’ve often used in previous blogs. If I wrote a Wines class that represented a collection of wines then it’s associated database table should also be called wines and not, for example, fermented_grape_juice. I could then write any handling or client software so that if it came across a class called Wines it would automatically assume the name associated database table.

The motivation for ‘convention over configuration’ is to cut down the mapping between a program and its resources with the result that it reduces program complexity, shortens development time, saves money and makes life simpler for everyone. Plus, writing config files is error prone and these kinds of errors only come to light at runtime, rather than compile-time.

Examples of frameworks that have moved, or are moving to ‘convention over configuration’ include Hibernate and Spring.

In the Spring 2.5 and 3 arenas, this can be demonstrated by the @Autowired annotation as using it replaces the Spring XML bean configuration file. For example, given the following fake datasource class and its client @Autowired classes:

@Component
public class FakaSource {

  public void execute() {

    System.out.println("Inside - execute of FakaSource");
  }
}

@Configuration
public class AutoWiredAppConfig {

  @Autowired
  private FakaSource datasource;

  @Bean
  public MyDAO createMyDataAccessObject() {

    return new AnyOldDAO(datasource);
  }
}

In this example, the convention is to mark your class with the @Autowired annotation. Spring will then read the annotation and inject a FakaSource into your AutoWiredAppConfig. If you were using Spring 2 then you’d need to add setters to the AutoWiredAppConfig class and explicitly link the two classes together using XML configuration, that looked something like,

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
       http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

 <bean id="fakeDataSource" class="FakaSource" />

 <bean id="appConfig" class="AutoWiredAppConfig">
  <property name="fakaSource">
   <ref local="fakeDataSource"/>
  </property>
 </bean> 
</beans>

...before Spring would do the dependency injection. Of course, in the context of XML config AutoWiredAppConfig is a totally inappropriate name for the class.

This is just a quick definition of ‘convention over configuration’, a more in-depth explanation can be found on wikipedia and at Software Engineering Matters