Lecture
Convention over configuration (also known as coding by convention, Convention over configuration ) is a software design paradigm used by software frameworks that attempts to decrease the number of decisions that a developer using the framework is required to make without necessarily losing flexibility. The concept was introduced by David Heinemeier Hansson to describe the philosophy of the Ruby on Rails web framework, but it is related to earlier ideas like the concept of "sensible defaults " and the principle of least astonishment in user interface design .
In essence, the phrase means that a developer only needs to specify the unconventional aspects of the application. For example, if the model has a class Sales , the corresponding table in the database is called "sales" by default. Only if one deviates from this convention, such as calling the table "product sales", does one need to write code for these names.
When the convention implemented by the tool matches the desired behavior, it behaves as expected without having to write configuration files. Only when the desired behavior deviates from the implemented convention is explicit configuration required.
The use of this phrase in Ruby on Rails focuses in particular on its default project file and directory structure, which spares developers from writing XML configuration files to specify which modules the framework should load, as was common in many earlier frameworks.
Disadvantages of the convention approach compared with the configuration approach can arise from conflicts with other software design principles, such as the Zen of Python's "explicit is better than implicit". Software frameworks based on convention over configuration often include a domain-specific language with a limited set of constructs, or an inversion of control in which the developer can influence behavior only by using a limited set of hooks , either of which can make implementing behavior that is not easily expressed in the provided conventions harder than when using a software library that does not try to reduce the number of decisions developers have to make or require inversion of control.
Other techniques for reducing the number of decisions a developer must make include programming idioms and configuration libraries with a layered architecture .
With this approach, developers only need to configure the application-specific and unconventional aspects of the application. Other aspects, such as wiring input elements through specialized models to database tables, can be provided by conventions such as naming classes and tables identically, and need to be configured only if the conventions are deviated from. For example, if the convention states that a model class should be named in the singular and the corresponding database table in the plural, the developer does not need to do any explicit configuration for a program with a model class Saleto use the table sales. But if the table is called something like products_sold, he must configure it.
Some frameworks require multiple configuration files, each with many settings. They provide information specific to each project, from URLs to mappings between classes and database tables. Many configuration files with many parameters are often hard to maintain.
For example, early versions of the Java persistence mapper Hibernate mapped entities and their fields to the database by describing these relationships in XML files. Most of this information could have been derived by the usual mapping of class names to database tables of the same name, and of fields to their columns, respectively. Later versions dropped the XML configuration file and instead used these very conventions, with deviations that can be specified using Java annotations (see the JavaBeans specification, referenced below).
Many traditional frameworks require multiple configuration files to set up project-specific parameters. These parameters affect not only global values but also repeating values for many elements of the application, such as the assignment of classes to database tables. As the size and complexity of an application grew, the size and complexity of these configuration files grew as well, which in turn reduced the maintainability of the application. Using annotations instead of configuration files does not eliminate this problem, but merely shifts it elsewhere.
Convention over configuration precisely reduces these often structurally repetitive entries in configuration files and annotations. This means that developers only need to learn the conventions underlying the framework and do not have to deal with a huge amount of configuration. This increases the maintainability of the application and thus reduces the overall cost of software development and maintenance.
Many modern frameworks use an approach based on convention over configuration .
However, the concept is older, going back to the concept of defaults, and can be found most recently in the roots of Java libraries . For example, the JavaBeans specification relies heavily on it. To quote the JavaBeans 1.01 specification
"In general we don't want to invent a huge java.beans.everything class that people have to inherit from. Instead, we'd like the JavaBeans runtime to provide default behavior for 'normal' objects, but to allow objects to override a given piece of default behavior by inheriting from some specific java.beans.something interface."
Figure 2. Convention over configuration in action
Fig. 1. Folder structure of a Visual Studio MVC project
Comparison of web frameworks
PSR (PHP Standards Recommendations)
Java specification requests
JSCS: JavaScript Code Style, Google JavaScript Style Guide
Python Enhancement Proposal
programming patterns
programming principles
programming paradigms
programming antipatterns
SQL Style Guide Database standards
Comments