Convention over Configuration is the principle that software defined by a convention will be easier to maintain than software driven by configuration. If you have used the Model/View/Controller implementation by Microsoft you will see that it is based heavily on this principle.
Using Microsoft MVC you identify what Controller is called by setting a URI pattern to the name of a controller class excluding the suffix “Constroller” in the class name. For example, an URI pattern may be http://localhost.myapplication/Customer, and by convention this will call into the controller class named CustomerController found in CustomerController.cs. This example is a composite of Convention and Configuration because there is a configuration entry that maps the URI pattern to a controller.
Probably a better example is that of the controller. It sees the action “Customer” in the URI and maps that to a method called Customer in the CustomerController class. Often that method is assigned to a View designed to represent that Customer Model, and is referred to in code simply as View. By convention MVC knows to translate the alias “View” into a CustomerView class.
There are a lot more examples of Convention over Configuration available to you. Fluent NHibernate is another example. NHibernate fully supports the use of Configuration files to map models to database storage. Fluent NHibernate takes the approach of using table and column properties and associating the object models of your code with the database tables and actions through a strict naming convention of your Class objects. If the naming convention is followed, then database persistence is easily implemented allowing the developer to focus on writing application code instead of maintaining object mappings in a configuration file of some sort.
Are you taking advantage of programming by Convention? Share your thoughts or experiences online. or drop me an email to btaylor@sswug.org.
Cheers,
Ben