Sunday, 4 January 2009

Convention versus patterns

With Ruby on Rails, one of the catch phrases has been “convention over configuration.” They argue that it is preferable to use standard conventions or approaches to implementation rather than utilise complex configuration options. This promotes faster development and more consistent systems. Most of the time the configuration comparisons have been with Java stacks where there are multiple layers all having to be configured to talk to one another. Programming a Flex user interface for a Java middle ware running in a JBoss server with an Oracle back end database with PL/SQL stored procedures, I am conscious of some of the configuration issues and the problems that occur if you get it wrong.

A convention aims to reduce the amount of set up required and to improve the development time. The convention tends to enforce certain implementation structures of the programmer. In the case of Rails, this tends to be CRUD (Create, Retrieve, Update, and Delete) style applications.

The more general meaning of convention is the notion that “this is how we do it.” When I taught DotNET programming, most of the available introductory text books used the DataSet as the means to access and manipulate data. This removed the notion of a domain model but made it fairly easy to write CRUD applications (I used to say CRUD by name and crud by nature). As a solution technique, the DataSet has its place and the programming conventions that developed around its use also have their appropriate context and problem space. The issue is that the convention isn't applicable in every circumstance.

Working in Flex but having done most of my thinking with respect to object-oriented with Java and the DotNET languages, I am finding that my approaches are often being challenged as “not the way that it is done in Flex”; that is I am not conforming to the Flex convention. The simplest case is that I tend to implement properties using get and set functions. It is quicker to write public variables but as an object-oriented convention that is frowned upon. In Java and DotNET, you can also use public variables but the clear message is to use getters and setters. I have simply transferred that thinking to Flex. Although I have to write more code, I would argue that using getters a setters potentially gives me better control.

I have previously argued that the MVC frameworks (Cairngorm and PureMVC) are more about conventions rather than the actual code framework that they provide (see post Flex MVC Frameworks). In relation to Cairngorm, those conventions can make it difficult although not impossible to write tests for and can add to the maintenance difficulties.

My thought is that if conventions are based on implementation patterns then those conventions will probably prove more durable. If a pattern has been defined correctly or at least following the convention for patterns then it should capture the common solution to a reoccurring problem. The pattern definition should provide the context in which the pattern is applicable, the problem to which it applies, the forces that are present in that situation, the essence of the solution, and the resulting context (both positive and negative consequences).

If conventions were defined in this way then a person looking at a convention would be able to tell whether that convention was appropriate for their situation. The problem is that a convention carries the stigma that this is the way that it is done.

The problem with frameworks, even though their original development may have been based on patterns, the way that they are used and talked about is often as conventions. But each framework has its restrictions and advantages. The user needs to be conscious of these when making the decision on which to apply.

The convention is a solution to a common problem but the programmer has not been made aware of the problem or the context in which it applies. Further the programmer is not provided with the resulting context especially the negative consequences.

If conventions were written up as a pattern language then the applicability of the conventions and their appropriate use would become more visible.

No comments: