La convención sobre la configuración (también conocida como codificación por convención ) es un paradigma de diseño de software utilizado por los marcos de software que intenta disminuir el número de decisiones que debe tomar un desarrollador que usa el marco sin perder necesariamente flexibilidad. El concepto fue introducido por David Heinemeier Hansson para describir la filosofía del marco web Ruby on Rails , pero está relacionado con ideas anteriores como el concepto de " valores predeterminados sensibles " y el principio del mínimo asombro en el diseño de la interfaz de usuario .
Básicamente, la frase significa que un desarrollador solo necesita especificar aspectos no convencionales de la aplicación. Por ejemplo, si hay una clase Ventas en el modelo, la tabla correspondiente en la base de datos se llama "ventas" por defecto. Sólo si uno se desvía de esta convención, como la tabla "ventas de productos", es necesario escribir un código con respecto a estos nombres.
Cuando la convención implementada por la herramienta coincide con el comportamiento deseado, se comporta como se esperaba sin tener que escribir archivos de configuración. Solo cuando el comportamiento deseado se desvía de la convención implementada, se requiere una configuración explícita.
El uso de Ruby on Rails de la frase se centra particularmente en su archivo de proyecto predeterminado y estructura de directorio, lo que evita que los desarrolladores tengan que escribir archivos de configuración XML para especificar qué módulos debe cargar el marco, lo cual era común en muchos marcos anteriores.
Las desventajas de la convención sobre el enfoque de configuración pueden ocurrir debido a conflictos con otros principios de diseño de software, como el "explícito es mejor que implícito" del Zen de Python . Un marco de software basado en la convención sobre la configuración a menudo implica un lenguaje específico de dominio con un conjunto limitado de construcciones o una inversión de control en la que el desarrollador solo puede afectar el comportamiento utilizando un conjunto limitado de ganchos , los cuales pueden hacer que la implementación de comportamientos no sea fácil. expresado por las convenciones proporcionadas más difícil que cuando se utiliza una biblioteca de software que no intenta disminuir el número de decisiones que los desarrolladores tienen que tomar o requieren una inversión de control.
Otros métodos para disminuir el número de decisiones que debe tomar un desarrollador incluyen modismos de programación y bibliotecas de configuración con una arquitectura de múltiples capas .
Motivación
Algunos marcos necesitan varios archivos de configuración, cada uno con muchas configuraciones. Estos proporcionan información específica para cada proyecto, desde URL hasta asignaciones entre clases y tablas de base de datos. Muchos archivos de configuración con muchos parámetros suelen ser difíciles de mantener.
Por ejemplo, las primeras versiones del mapeador de persistencia de Java Hibernate mapeaban entidades y sus campos a la base de datos describiendo estas relaciones en archivos XML. La mayor parte de esta información podría haberse revelado mapeando convencionalmente los nombres de las clases a las tablas de la base de datos con nombres idénticos y los campos a sus columnas, respectivamente. Las versiones posteriores eliminaron el archivo de configuración XML y, en su lugar, emplearon estas mismas convenciones, cuyas desviaciones pueden indicarse mediante el uso de anotaciones Java (consulte la especificación JavaBeans, vinculada a continuación).
Uso
Muchos marcos modernos utilizan una convención sobre el enfoque de configuración .
Sin embargo, el concepto es más antiguo, se remonta al concepto de predeterminado y se puede encontrar más recientemente en las raíces de las bibliotecas de Java . Por ejemplo, la especificación JavaBeans se basa en gran medida en él. Para citar la especificación JavaBeans 1.01: [1]
"Como regla general, no queremos inventar una enorme clase java.beans.everything de la que la gente tenga que heredar. En su lugar, nos gustaría que los tiempos de ejecución de JavaBeans proporcionen un comportamiento predeterminado para objetos 'normales', pero que permitan que los objetos anular una parte determinada del comportamiento predeterminado heredando de alguna interfaz java.beans.something específica ".
Ver también
Referencias
- ^ Sun (24 de julio de 1997). Especificación de JavaBeans Archivado el 6 de abril de 2012 en Wayback Machine , sección 1.4.
- Bachle, M. y Kirchberg, P. (2007). "Ruby on Rails". Software IEEE, 24 (6), 105-108. DOI 10.1109 / BCI.2009.31 .
- Miller, J. (2009). "Diseño para convención sobre configuración". Microsoft, obtenido el 18 de abril de 2010.
- Chen, Nicholas (2006). "Convención sobre configuración".