Configuration is data that tells the system how to function. It often can be changed while the system is running to do something else. Configuration is good because the system isn’t hard-coded in its behavior and can be changed based on the allowable configuration options.
One major consideration with configuration is volume. There are systems with so much configuration that managing the configuration takes a lot of time and overhead. With Microsoft applications, I’ve seen this with configuration spread among config files, databases, and other data sources. In Salesforce, the configuration is usually in Custom Settings, Objects, and Custom Metadata Types. The overhead comes from not just developing the software to support the various options but documenting the configuration options and training others about the options too.
“Convention Over Configuration” Design Principle
A Convention is a standard or agreed upon way of doing things. In the software context, if things are done a certain way, the software will behave this way without having to be configured to do so.
Running Tests Example
In my Automated Unit Test Execution Salesforce Cookbook Recipe, the code runs apex classes that start with “Test”. As long as someone creates a new test class with the naming convention “Test<class_name>”, their tests will automatically run without having to tell the system to do so.
ASP.NET MVC Example
In ASP.NET MVC, views are automatically bound to their corresponding data entities as long as the same name is used in the view and the binding property on the underlying entity. This is great because in ASP.NET WebForms and other web frameworks, a decent amount of scaffolding code was marshalling the data from the view to the model and vice-versa.
Whenever possible, I prefer to use convention over configuration to ease software overhead. However, there may be convention exceptions that need to be considered so the software can behave differently from the convention. This can be implemented with convention overrides or with configuration using a hybrid approach. I.E. convention and configuration.
As with any design principle, “convention over configuration” has to be considered in the context of the system in which it’s used to see if it makes sense to use.
What do you think of “Convention Over Configuration”? What other examples do you have? Do you have other patterns that drive system behavior without configuration?