A “convenção sobre configuração” não está violando os princípios básicos de programação?

Eu não considero que "um aplicativo deve ser totalmente explicado pelo seu próprio código", um princípio fundamental de programação. Há muitas e muitas coisas que não são explicadas apenas olhando o código de um aplicativo. Além de conhecer as coisas básicas da própria linguagem de programação (sintaxe e semântica), você precisa conhecer as convenções. Se um identificador em Java começar com uma letra maiúscula, é um tipo. Existem muitas dessas convenções que você precisa saber.

A convenção sobre configuração é sobre reduzir a quantidade de decisões que o programador deve tomar sobre as coisas. Para algumas coisas, isso é óbvio - ninguém consideraria ter uma linguagem em que a capitalização dos tipos é algo que você precisa declarar no topo do programa - mas, para outras coisas, isso não é tão óbvio.

A convenção e configuração de balanceamento é uma tarefa difícil. Muita convenção pode tornar o código confuso (use as variáveis implícitas do Perl, por exemplo). Muita liberdade do lado do programador pode tornar os sistemas difíceis de entender, uma vez que o conhecimento adquirido em um sistema raramente é útil quando se estuda outro.

Um bom exemplo de onde a convenção ajuda o programador ao escrever plug-ins do Eclipse. Ao olhar para um plugin que eu nunca vi, eu imediatamente sei muitas coisas sobre isso. A lista de dependências está em MANIFEST.MF, os pontos de extensão estão em plugin.xml, o código-fonte está em "src" e assim por diante. Se essas coisas dependessem do programador para definir, cada plug-in do Eclipse seria diferente, e a navegação por código seria muito mais difícil.

Deu +1 para @JesperE e gostaria de adicionar algo:

is it violating some programming principles

Sim, "convenção sobre configuração" viola o princípio "explícito é melhor que implícito" (dê uma olhada, por exemplo, em Zen-Of-Python" ).

Por outro lado, o oposto "configuração sobre convenção" tende a violar "Simples é melhor que complexo" e, pior, viola o Princípio DRY de maneira sutil, pois você precisa repetir nomes usados em seu código também em sua configuração.

Algumas das "convenções sobre configuração" se resumem a padrões sensatos. Você só precisa configurar algo para usá-lo para fins não padronizados. Eu tenho que comparar Struts to Rails aqui. No Rails, você tem que colocar suas "ações / telas" em uma pasta e elas simplesmente funcionam. No Struts, você ainda precisa colocá-los em uma pasta, mas também precisa criar um nome de ação AND um arquivo JSP E um nome de formulário E um bean de formulário E especifique como essas três coisas funcionam juntas no Struts-config. xml E especifica que o formulário pertence ao pedido (RESTful). Se isso não for suficiente, o mapeamento form / form-bean tem sua própria seção no Struts-config, que é então mapeada independentemente para a seção action no mesmo arquivo e tudo depende de strings manuscritas no arquivo JSP para funcionar devidamente. Para cada tela, são pelo menos 6 coisas que você não deveria ter que fazer e tantas oportunidades para cometer um erro. Eu acho que você pode configurar a maioria ou todas essas coisas manualmente no Rails se você precisar, mas 2/3 do tempo de desenvolvimento do Struts é feito construindo e mantendo camadas desnecessárias de complexidade.

Com toda a justiça, o Struts 1 foi criado quando as pessoas estavam portando aplicativos entre a área de trabalho e a web. A flexibilidade que o Struts criou torna-o adequado para tudo que o Rails faz, além de tudo que um aplicativo de desktop precisa. Infelizmente, a montanha de configuração que permite essa flexibilidade é uma enorme bola e corrente para alguém que precisa apenas escrever um aplicativo da web ou apenas um aplicativo de desktop.

Eu trabalhei em algum lugar que eles deram o próximo passo e argumentaram, "Configuração sobre Código " mas tendo visto isso levado ao seu extremo lógico, o resultado é que a configuração se torna uma nova linguagem de codificação. Era um jogo em que a complexidade era empurrada sem ser domada de maneira significativa. E isso me deu uma apreciação por toda a verificação de tipos e outras redes de segurança que uma linguagem de programação bem projetada tem. Algum formato de arquivo de configuração semi-cozido que explode sem mensagem de erro se você adicionar um espaço ou um apóstrofo NÃO é uma melhoria em relação a uma linguagem de programação de qualidade que possui conjuntos de ferramentas de edição e um compilador de qualidade.

Eu não posso imaginar que ter padrões sensatos viola quaisquer princípios teóricos sobre extensibilidade e modularidade. Um programador Ruby / Rails preferiria jogar um poker mais quente do que mudar para um framework como o Struts 1, onde todas as configurações são feitas explicitamente em vários arquivos XML. Eu não estou discutindo Rails vs. Struts EM GERAL, mas essa convenção pode ser uma grande vitória de produtividade. Essas duas tecnologias são a comparação mais extrema do mundo real que encontrei.

Se você trabalha em Java, confira Joshua Bloch's, "Effective Java," Item 2: "Considere um construtor quando confrontado com muitos parâmetros de construtor" pp. 11-16. Para a maioria dos propósitos, alguns parâmetros (configuração) são requeridos, e alguns são opcionais. A idéia básica é exigir apenas a configuração necessária e apenas fazer com que o usuário (que poderia ser outro programa) especifique opções adicionais conforme necessário. Eu limpei um monte de código com este padrão há um mês e ele brilha 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.

A funcionalidade de uma aplicação que usa uma estrutura é sempre dependente da estrutura, a convenção sobre configuração não faz diferença a esse respeito.

Na minha experiência, a convenção sobre a configuração não apenas torna o código mais legível, mas também reduz a possibilidade de introduzir bugs sutis (especialmente copy-paste-bugs).

Por exemplo, suponhamos que em algum framework A, o evento FooBar aciona uma chamada para handleFooBar . Em outro framework B, essa correlação é configurada em algum lugar em um arquivo XML.

Então, em A, é simplesmente

handleFooBar() {
   ...
}

e, a menos que você tenha digitado errado o FooBar, ele será chamado sempre que o FooBar acontecer.

Em B, é novamente

handleFooBar() {
   ...
}

mas também

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

Com centenas de coisas para configurar dessa forma, é muito fácil criar acidentalmente um bug sutil como

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

porque depois de copiar e colar, só alteramos <type> , mas esquecemos de alterar <handler> .

Como esses arquivos de configuração são grandes e monótonos, é menos provável que alguém encontre o bug por revisão do que ele encontraria um bug semelhante no código real do programa.

Pode estar violando alguns princípios, mas, ao mesmo tempo, obedece a um dos princípios de design mais fundamentais, o SRP (Princípio da Responsabilidade Única).