¿La "convención sobre la configuración" no viola los principios básicos de programación?

No considero que "una aplicación deba explicarse completamente por su propio código" es un principio de programación fundamental. Hay muchas cosas que no se explican con solo mirar el código de una aplicación. Además de conocer las cosas básicas del propio lenguaje de programación (sintaxis y semántica), es necesario conocer las convenciones. Si un identificador en Java comienza con una letra mayúscula, es un tipo. Hay muchas de estas convenciones que debes conocer.

La convención sobre la configuración consiste en reducir la cantidad de decisiones que el programador tiene que tomar sobre las cosas. Para algunas cosas esto es obvio: nadie consideraría tener un lenguaje en el que la mayúscula de los tipos sea algo que deba declarar en la parte superior de su programa, pero para otras cosas no es tan obvio.

Equilibrar la convención y la configuración es una tarea difícil. Demasiada convención puede hacer que el código sea confuso (tome las variables implícitas de Perl, por ejemplo). Demasiada libertad por parte del programador puede hacer que los sistemas sean difíciles de entender, ya que el conocimiento obtenido de un sistema rara vez es útil cuando se estudia otro.

Un buen ejemplo de dónde colabora el programador con las convenciones es al escribir complementos de Eclipse. Al mirar un complemento que nunca he visto, inmediatamente sé muchas cosas sobre él. La lista de dependencias está en MANIFEST.MF, los puntos de extensión están en plugin.xml, el código fuente está en "src", y así sucesivamente. Si estas cosas pudieran ser definidas por el programador, cada uno de los complementos de Eclipse sería diferente, y la navegación del código sería mucho más difícil.

Dio +1 a @JesperE y me gustaría agregar algo:

  

está violando algunos principios de programación

Sí, "convención sobre configuración" viola el principio "explícito es mejor que implícito" (eche un vistazo, por ejemplo, a " Zen-Of-Python ").

Por otra parte, la "configuración sobre convención" opuesta tiende a violar "Simple es mejor que complejo", y peor aún, viola principio DRY de una manera sutil, ya que necesita repetir los nombres utilizados en su código también en su configuración.

Algunas de las "convenciones sobre la configuración" solo se reducen a valores predeterminados razonables. Solo debe tener que configurar algo para usarlo para un propósito no estándar. Tengo que comparar Struts con Rails aquí. En Rails, tienes que poner tus "acciones / pantallas" en una carpeta y luego simplemente funcionan. En Struts, todavía tiene que ponerlos en una carpeta, pero también debe tener un nombre de acción Y un archivo JSP Y un nombre de formulario Y un bean de formulario Y especificar cómo estas tres cosas funcionan juntas en Struts-config. xml Y especifique que el formulario pertenece a la solicitud (RESTful). Si eso no es suficiente, la asignación form / bean forma tiene su propia sección en Struts-config que luego se asigna independientemente a la sección de acción en el mismo archivo y todo se basa en cadenas manuscritas en el archivo JSP para funcionar. correctamente. Para cada pantalla, hay al menos 6 cosas que no debes hacer y tantas oportunidades para cometer un error. Creo que puedes configurar la mayoría o todas esas cosas manualmente en Rails si lo necesitas, pero se toman 2/3 del tiempo de desarrollo de Struts construyendo y manteniendo capas de complejidad innecesarias.

Para ser justos, Struts 1 fue diseñado cuando las personas portaban aplicaciones entre el escritorio y la web. La flexibilidad que Struts ha incorporado lo hace adecuado para todo lo que hace Rails, además de todo lo que una aplicación de escritorio podría necesitar. Desafortunadamente, la montaña de configuración que permite esa flexibilidad es una gran bola y cadena para alguien que solo necesita escribir una aplicación web o simplemente una aplicación de escritorio.

Trabajé en algún lugar donde dieron el siguiente paso y argumentaron, "Configuración sobre Código ", pero habiendo visto que lo llevaron a su extremo lógico, el resultado es que la configuración se convierte en un nuevo lenguaje de codificación. Fue un juego de shell en el que la complejidad se desplazó sin ser domesticada de manera significativa. Y me dio una apreciación por todas las redes de verificación de tipos y de seguridad que tiene un lenguaje de programación bien diseñado. Algunos formatos de archivos de configuración semicocidos que aparecen sin mensajes de error si agrega un espacio o un apóstrofe NO es una mejora sobre un lenguaje de programación de calidad que tiene conjuntos de herramientas de edición y un compilador de calidad escrito para él.

No puedo imaginar que tener valores predeterminados razonables viole cualquier principio teórico sobre la extensibilidad y la modularidad. Un programador de Ruby / Rails preferiría poner un póquer caliente en su ojo que cambiar a un marco como Struts 1 donde todas las configuraciones se realizan explícitamente en múltiples archivos XML. No estoy discutiendo Rails vs. Struts EN GENERAL, pero esa convención puede ser una gran ganancia de productividad. Estas dos tecnologías son la comparación más extrema del mundo real que he encontrado.

Si trabajas en Java, echa un vistazo a Joshua Bloch, "Effective Java", elemento 2: "Considera un generador cuando te encuentres con muchos parámetros de constructor", páginas 11-16. Para la mayoría de los propósitos, algunos parámetros (configuración) son necesarios, y algunos son opcionales. La idea básica es requerir solo la configuración necesaria y solo hacer que el usuario (que podría ser otro programa) especifique opciones adicionales según sea necesario. Limpié un montón de código con este patrón hace un mes y brilla positivamente.

  

En otras palabras, la funcionalidad de la aplicación no se explica completamente por su propio código, sino también por la documentación del marco.

La funcionalidad de una aplicación que utiliza un marco depende siempre del marco, la convención sobre la configuración no hace una diferencia en ese sentido.

En mi experiencia, la convención sobre la configuración no solo hace que el código sea más legible, sino que también reduce la posibilidad de introducir errores sutiles (especialmente errores copiar-pegar).

Por ejemplo, supongamos que en algún marco A, el evento FooBar desencadena una llamada a handleFooBar . En otro marco B, esta correlación se configura en algún lugar en un archivo XML.

Por lo tanto, en A, es simplemente

handleFooBar() {
   ...
}

y, a menos que hayas escrito incorrectamente FooBar, se llamará cuando suceda FooBar.

En B, es otra vez

handleFooBar() {
   ...
}

pero también

<eventconfiguration>
  <event>
    <type>FooBar</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

Con cientos de cosas para configurar de esta manera, es muy fácil crear accidentalmente un error sutil como

<eventconfiguration>
  <event>
    <type>BarFoo</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

porque después de copiar y pegar, solo cambiamos <type> , pero nos olvidamos de cambiar <handler> .

Dado que esos archivos de configuración son grandes y monótonos, es menos probable que alguien encuentre el error mediante la corrección de pruebas que un error similar en el código real del programa.

Puede estar violando algunos principios, pero al mismo tiempo obedece a uno de los principios de diseño más fundamentales, SRP (Principio de Responsabilidad Única).