Design Principles vs. Design Patterns

Off late, during the interviews and during various design discussions, I have come across few developers who are confused about this design principle called "Convention over Configuration". They are not sure when to use this principle as they were clueless about the pros and cons which could be due to their lack of experience or an exposure. That's when I felt that I should document my thoughts through this article.

First of all, let's try to understand each of these terms called Configuration and Convention separately before looking into the details.

Configuration

There are two factors that developers think of when it comes to configuration.

• Environment specific configuration - This is preferred when the properties are environment or framework specific. For e.g., database host and port. They are obviously are expected to vary, and hence this should be considered.

• Application specific configuration - This is preferred when some properties does not depend on any given environment, but you would still prefer to configure, so that you want to avoid any means of hard coding, as hard coding leads to code change and error prone. For e.g., a path to configuration file that need to be loaded during the application startup.

• Database based configuration - This is preferred when the properties are business driven and going to be more dynamic in nature and could influence the business logic or application behavior, and whose state has to be maintained throughout the application life-cycle. This approach also requires administration capabilities to be built so that the properties can be managed and modified such that it could change the application behavior at runtime without testing and deployment. For e.g., roles and permissions, commission rates, etc.

In fact, I have come across few developers who are confused with the above ones too, and they still struggle when it comes to picking the right approach. I hope the above explanation provides better clarity.

Now, let's discuss about convention...

Convention

When it comes to configuration driven approach, it depends on the framework that you would be using, and also the file formats could vary. For e.g., the old way of configuration used to be PROPERTIES bundle which were linear and plain text. Then it evolved into XML based as it provided much better of configuring complex properties in a structured fashion. Nowadays, developers prefer .yaml format as most of the frameworks do support.

However, the developers are required to know the syntax and semantics of those formats. This could potentially to lead to learning curve, and error prone as one will get to know errors only when the application boots up, and loads the configuration. This will make developers less productive.

Remember, the configuration (environment or framework or application) is always done by the developers. They do it according to the requirements. So why not do the same in the code instead of doing it in 3rd party location or a format. The approach that you take to configure such properties directly in the code is called as convention. Some of the benefits of convention over configuration are:

• Type safe.

• Both human and machine readable.

• Easier to understand and debug, as it's tied to the programming language or frameworks that developers are using.

• Less error prone as annotations are syntactically checked at compile time. In fact, most of the IDEs are capable of identifying errors with semantics, at compile time too.

Conclusion

Due to it's advantages over configuration, convention is the preferred way. Having said that, there could be hybrid approach too wherein you can prefer to define some properties through configuration, and some through conventions. It is also possible to define the properties in both configuration convention way. Remember, in such cases the configuration approach over-writes the convention approach. Also, one should be mindful of the fact about the configuration approach, is that too much of distributed configurations (like hybrid ones) could lead to complexities and difficult to manage. This is usually called as "Configuration Hell", and I will make an attempt to write an article/blog on the same.

The reason why "Convention over Configuration" is design principle, because the decision is made during the design time and not at runtime (unlike database based configuration as described above). While making decision, the first preference should go to convention and if the properties cannot be defined through convention, then go for configuration.