La "convenzione sulla configurazione" non viola i principi di programmazione di base?

Non considero "un'applicazione dovrebbe essere pienamente spiegata dal proprio codice" un principio di programmazione fondamentale. Ci sono un sacco di cose che non sono spiegate semplicemente guardando il codice di un'applicazione. Oltre a conoscere le cose basilari del linguaggio di programmazione stesso (sintassi e semantica), è necessario conoscere le convenzioni. Se un identificatore in Java inizia con una lettera maiuscola, è un tipo. Ci sono molte di queste convenzioni che devi conoscere.

La convenzione sulla configurazione riduce la quantità di decisioni che il programmatore deve prendere sulle cose. Per alcune cose questo è ovvio - nessuno prenderebbe in considerazione l'idea di avere una lingua in cui la capitalizzazione dei tipi è qualcosa che devi dichiarare in cima al tuo programma - ma per altre cose non è così ovvio.

La convenzione e la configurazione di bilanciamento sono un compito difficile. Troppe convenzioni possono rendere il codice confuso (prendi le variabili implicite di Perl, per esempio). Troppa libertà dal lato del programmatore può rendere i sistemi difficili da capire, poiché la conoscenza acquisita da un sistema è raramente utile quando si studia un'altra.

Un buon esempio di dove la convenzione aiuta il programmatore è quando si scrivono i plugin di Eclipse. Quando guardo un plugin che non ho mai visto, so subito molte cose a riguardo. L'elenco delle dipendenze è in MANIFEST.MF, i punti di estensione sono in plugin.xml, il codice sorgente è in "src" e così via. Se queste cose dovessero essere definite dal programmatore, ogni singolo plugin Eclipse sarebbe diverso e la navigazione del codice sarebbe molto più difficile.

Ha dato +1 a @JesperE e mi piace aggiungere qualcosa:

is it violating some programming principles

Sì, la "convenzione sulla configurazione" viola il principio "l'esplicito è meglio di quello implicito" (dai un'occhiata, ad esempio, a " Zen-Of-Python ").

D'altro canto, l'opposta "configurazione sulla convenzione" tende a violare "Semplice è meglio che complesso" e, peggio, viola il Principio ASCIUTTO in modo sottile, dal momento che devi ripetere i nomi usati nel tuo codice anche nella tua configurazione.

Alcune "convenzioni sulla configurazione" si riducono a valori predefiniti sensibili. Dovresti solo configurare qualcosa per usarlo per uno scopo non standard. Devo confrontare Struts to Rails qui. In Rails, devi mettere le tue "azioni / schermate" in una cartella e poi funzionano. In Struts, devi ancora metterli in una cartella, ma devi anche creare un nome di azione AND un file JSP E un nome di modulo AND un bean di form E specificare come queste tre cose funzionano insieme in Struts-config. xml E specificare che il modulo appartiene alla richiesta (RESTful). Se ciò non è sufficiente, il mapping form / bean ha la propria sezione in Struts-config che viene poi mappata indipendentemente alla sezione azione nello stesso file e tutto fa affidamento su stringhe scritte a mano nel file JSP per funzionare propriamente. Per ogni schermata, ci sono almeno 6 cose che non dovresti fare e altrettante opportunità di fare un errore. Penso che tu possa impostare la maggior parte o tutte quelle cose manualmente in Rails se necessario, ma 2/3 del tempo di sviluppo di Struts sono occupati a costruire e mantenere livelli di complessità non necessari.

In tutta onestà, Struts 1 è stato progettato quando le persone eseguivano il porting delle applicazioni tra desktop e web. La flessibilità offerta da Struts lo rende adatto a tutto ciò che fa Rails, oltre a tutto ciò di cui ha bisogno un'applicazione desktop. Sfortunatamente, la montagna di configurazione che consente tale flessibilità è un'enorme palla al piede per qualcuno che ha solo bisogno di scrivere un'app Web o solo un'app desktop.

Ho lavorato da qualche parte che hanno fatto il passo successivo e hanno argomentato, "Configurazione su Codice " ma, visto che è stato portato al suo estremo logico, il risultato è che la configurazione diventa un nuovo linguaggio di programmazione. E 'stato un gioco di shell in cui la complessità è stata spinta in giro senza essere addomesticata in alcun modo significativo. E mi ha dato un apprezzamento per tutti i controlli di tipo e altre reti di sicurezza che ha un linguaggio di programmazione ben progettato. Alcuni formati di file di configurazione semicotti che si aprono senza alcun messaggio di errore se si aggiunge uno spazio o un apostrofo NON è un miglioramento rispetto a un linguaggio di programmazione di qualità che ha suite di strumenti di modifica e un compilatore di qualità scritto per questo.

Non riesco a immaginare che avere valori predefiniti sensibili viola qualsiasi principio teorico sull'estensibilità e la modularità. Un programmatore di Ruby / Rails farebbe presto un poker caldo nei suoi occhi piuttosto che passare a un framework come Struts 1 in cui tutte le configurazioni sono esplicitate in più file XML. Non sto discutendo Rails vs. Struts IN GENERAL, ma quella convenzione può essere una grande vittoria di produttività. Queste due tecnologie sono il paragone più estremo del mondo reale che ho incontrato.

Se lavori in Java, dai un'occhiata a Joshua Bloch, "Effective Java", articolo 2: "Considera un costruttore in presenza di molti parametri del costruttore", pp. 11-16. Per la maggior parte degli scopi, sono necessari alcuni parametri (configurazione) e alcuni sono facoltativi. L'idea di base è di richiedere solo la configurazione necessaria e solo rendere l'utente (che potrebbe essere un altro programma) specificare opzioni aggiuntive secondo necessità. Ho ripulito un po 'di codice con questo modello un mese fa e brilla positivamente.

In other words, the functionality of the application is not completely explained by its own code, but also by the documentation of the framework.

La funzionalità di un'applicazione che utilizza un framework è always dipende dal framework, la convenzione sulla configurazione non fa differenza in questo senso.

Nella mia esperienza, la convenzione sulla configurazione non solo rende il codice più leggibile, ma riduce anche la possibilità di introdurre bug sottili (in particolare i bachi di copia-incolla).

Ad esempio, supponiamo che in alcuni framework A l'evento FooBar attivi una chiamata a handleFooBar . In un altro framework B, questa correlazione è configurata da qualche parte in un file XML.

Quindi, in A, è semplicemente

handleFooBar() {
   ...
}

e a meno che non abbiate scritto male FooBar, verrà chiamato ogni volta che si verifica FooBar.

In B, è di nuovo

handleFooBar() {
   ...
}

ma anche

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

Con centinaia di cose da configurare in questo modo, è fin troppo facile accidentalmente creare un bug sottile come

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

perché dopo il copia-incolla, abbiamo modificato solo <type> ma abbiamo dimenticato di cambiare <handler> .

Poiché questi file di configurazione sono grandi e monotoni, è meno probabile che qualcuno rilevi il bug tramite la correzione di bozze piuttosto che trovare un bug simile nel codice di programma effettivo.

Potrebbe violare alcuni principi, ma allo stesso tempo obbedire a uno dei principi di progettazione più fondamentali, SRP (Single Responsibility Principle).