Uma defesa para clichê?

14

Para mim, o código clichê é obviamente ruim. No entanto, conheci um desenvolvedor que exibe resistência em qualquer tentativa de reduzir o clichê. Percebi que não tinha um argumento bem formado, bem pensado, além da aversão que desenvolvi ao longo do tempo.

Para que eu possa formar um argumento convincente para favorecer menos clichê, quais são alguns contra-argumentos? Em outras palavras, quais são os argumentos (se houver) em favor do clichê?

(Eu quero dizer o que eu acho que é geralmente significado de boilerplate, mas um bom exemplo é getters e setters em Java.)

    
por abstracted 14.05.2012 / 20:52
fonte

7 respostas

12

Uma coisa importante a lembrar é que o código geralmente fica menor, removendo o contexto desnecessário. Se o compilador puder descobrir alguma coisa, o argumento, não há necessidade de escrevê-lo explicitamente.

E isso seria ótimo se o compilador tivesse a intenção de lê-lo. Mas lembre-se de que "os programas devem ser escritos para as pessoas lerem e, só por acaso, para as máquinas executarem". (Ironicamente, esta citação vem de um livro didático dedicado a uma das mais difíceis de todas as línguas para seres humanos comuns lerem, devido em grande parte à sua excessiva terseness.)

O que pode parecer um clichê chato e repetitivo para você enquanto você o está escrevendo pode ser um contexto valioso para alguém que aparece um ano (ou cinco) mais tarde e precisa manter seu código.

WRT o exemplo Java especificamente, eu vou concordar que esse é um bom exemplo de boiler, já que ele pode ser substituído por algo mais curto e mais fácil de ler, e também mais flexível: . Mas isso não significa que todos os elementos sintáticos padronizados de todas as linguagens sejam tão inúteis quanto os getters e setters de Java e C ++.

    
por 14.05.2012 / 21:05
fonte
7

Um argumento a favor do código clichê é que, se você alterá-lo em um lugar, isso afeta apenas um fluxo do código. Isso tem que ser equilibrado com o fato de que, na maioria das vezes, você quer que uma alteração afete cada parte do código que a utiliza. Mas eu vi exemplos raros que suportam o argumento.

Digamos que você tenha um trecho de código que diga

public ForTheBar(Foo foo)
{
    Bar bar = foo.bar();
    return bar.BeFooed();
}

Isso é usado em cerca de dois lugares em seu código.

Um dia alguém vem e diz "ok, só neste caminho, nós queremos que você Grommit o bar antes de Fooing."

E você pensa "bem, isso é simples".

public ForTheBar(Foo foo, bool shouldIGrommit)
{
    Bar bar = foo.bar();

    if (shouldIGrommit)
    {
        bar.BeGrommitted();
    }

    return bar.BeFooed();
}

Então o seu usuário adiciona algumas novas funcionalidades e você acha que se encaixa bem com o FooTheBar. E você obedientemente pergunta se você deveria Grommitar aquele bar antes de você e eles dizem "não, não desta vez".

Então você acabou de chamar o método acima.

Mas, em seguida, o usuário diz "ok, espera, no terceiro caso, queremos que você defina a barra antes de chamar o BeFooed".

Não tem problema, você acha, eu posso fazer isso.

public ForTheBar(Foo foo, bool shouldIGrommit, bool shouldIDoodle)
{
    Bar bar = foo.bar();

    if (shouldIGrommit)
    {
        bar.BeGrommitted();
    }

    if (shouldIDoodle)
    {
        bar.BeDoodled();
    }

    return bar.BeFooed();
}

De repente, seu código está se tornando menos clichê. Talvez você devesse ter aceitado as duas linhas repetidas de código. Até agora você teria três pedaços de código, cada um com 2-3 linhas de comprimento e não parecendo muito repetido.

Tudo isso dito, eu iria contrariar isso com "este não é um caso comum, e quando isso acontece, você pode refatorar."

Outro argumento que ouvi recentemente é que o código clichê às vezes pode ajudá-lo a navegar pelo código. O exemplo que estamos discutindo foi onde removemos toneladas de código de mapeamento padrão e o substituímos pelo AutoMapper. Agora, foi argumentado, porque tudo é baseado em convenção, você não pode dizer "Onde está essa propriedade definida" para o IDE e esperar que ele saiba.

Eu vi pessoas argumentarem coisas semelhantes sobre contêineres IoC.

Não quer dizer que eu concordo com eles, mas é um argumento justo, no entanto.

    
por 14.05.2012 / 21:46
fonte
6

A evolução da eficiência

Você começa com isto:

<p>
    <label for="field">My field</label>
    <input type="text" id="field">
</p>

então você se livra de todo esse clichê irritante e coloca-o em uma função:

  1. createFieldHtml( id, label )

    isso é bom, estou me poupando de tantas linhas!

  2. createFieldHtml( id, label, defaultValue )

    sim, também preciso de um valor padrão, fácil de adicionar.

  3. createFieldHtml( id, label, defaultValue, type )

    legal, eu posso usá-lo para caixas de seleção agora também

  4. createFieldHtml( id, label, defaultValue, type, labelFirst )

    Designer de UX disse que o rótulo tem que estar após a caixa de seleção.

  5. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate )

    agora processa um selecionador de data quando necessário. Hm .. params estão ficando um pouco fora de mão

  6. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate, containerCssClasses )

    houve um caso em que precisei adicionar classes CSS

  7. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate, containerCssClasses, fieldCssClasses, disabled, clearAfter, helpText, uploadPath )

    aaaaaaaaaaaaaaaaaaaaa

Em defesa do clichê

Eu tenho dificuldade em colocar isso em palavras porque é algo que eu tenho notado recentemente, então vou fazer uma lista:

  1. Parece-me que há um certo medo de ter linhas duplicadas que se estendem um pouco. Se são apenas algumas linhas, pode não haver problema algum. algumas coisas são inerentemente "quase repetitivas" (como no exemplo acima). Eu vejo pouca chance de otimizar a longo prazo.
  2. As pessoas adoram encapsular a funcionalidade em algum lugar; se você olhar objetivamente e parecer que está apenas "escondendo a bagunça" - seja suspeito! pode ser a hora de um bom e velho clichê
  3. Quando você tem uma função que se torna mais e mais poderosa; que leva muitos caminhos de execução diferentes, dependendo da entrada e, finalmente, faz muito pouco - pode ser tempo clichê!
  4. Quando você adiciona uma camada de abstração sobre outra camada de abstração, mas apenas para tornar seu código mais curto (a camada subjacente não deve ser alterada) - tempo clichê!
  5. Quando você tem uma função que precisa de tantos parâmetros que você precisa para ter parâmetros nomeados - talvez seja o tempo clichê.

Uma coisa que eu sempre me pergunto recentemente é esta:
Posso copiar e colar em outro projeto sem alterar nada? se sim, não há problema em encapsular ou colocar em uma biblioteca, se não: é o tempo padrão.

Isso se opõe muito à percepção geral de que clichê é copiar e colar código. Para mim, clichê é sobre copiar e colar, mas sempre tendo que ajustá-lo um pouquinho.

Atualização : Acabei de encontrar um artigo dando meu exemplo acima de um nome real: "anti-padrão DRY demais".

The function gets more parameters and has increasingly complex internal logic to control its behavior in different cases. Too DRY functions are easy to spot. They have lots of intricate if-then logic that try to address a wide diversity of usage. [...] Also, repeating code isn’t always a bad thing if the code is small and performs a discrete function.

É uma leitura curta e interessante, você pode encontrar o artigo aqui: Anti-padrão muito seco

    
por 15.05.2012 / 04:04
fonte
4

Eu desprezo código clichê, mas ser capaz de remover código clichê nem sempre significa que é o melhor caminho a seguir.

A estrutura do WPF tem propriedades de dependência , que envolvem uma quantidade insana de código clichê. Durante o meu tempo livre investiguei uma solução que reduz muito a quantidade de código que precisa ser escrito. Mais de um ano depois, ainda estou melhorando essa solução , e ainda preciso estender em sua funcionalidade ou corrigir bugs.

Qual é o problema? Isso é ótimo para aprender coisas novas e explorar soluções alternativas, mas provavelmente não é a melhor decisão comercial .

A estrutura do WPF está bem documentada. Ele apropriadamente documenta como escrever seu código clichê. Tentar remover este código clichê é um bom exercício, e algo que definitivamente vale a pena ser explorado, mas conseguir o mesmo nível de 'polonês' que as ofertas do msdn leva muito tempo, o que nem sempre temos.

    
por 14.05.2012 / 21:34
fonte
1

O problema com clichê é que ele viola DRY. Em essência, quando você escreve clichê, você está repetindo o mesmo código (ou código muito semelhante) em várias classes. Quando esse código precisa ser alterado, não é de todo certo que o desenvolvedor se lembrará de todos os lugares em que o código foi repetido. Isso leva a erros nos quais APIs antigas ou métodos antigos são usados.

Se você refatorar o clichê em uma biblioteca ou classe pai comum, só precisará alterar o código em um lugar quando a API mudar. Mais importante, quando mudanças inesperadas acontecem, o código quebra em um lugar, e permite que você saiba exatamente o que você precisa corrigir para que tudo funcione novamente. Isso é muito preferível a um cenário em que uma alteração causa falhas em dezenas ou até centenas de classes.

    
por 14.05.2012 / 21:15
fonte
0

Vou tomar um tato diferente. A consistência no desenvolvimento é uma das características mais importantes do design de software, é uma ferramenta crítica para tornar os aplicativos extensíveis e de fácil manutenção, mas pode ser difícil de alcançar ao gerenciar uma equipe em vários sites, idiomas e fusos horários.

Se alcançado, a consistência torna o código muito mais acessível "uma vez que você viu um, você já viu todos eles", muito mais barato para manter e refatorar, mas acima de tudo, muito mais fácil de estender. Quando você escreve uma biblioteca que requer algum clichê, junto com o poder da sua biblioteca, você também deu ao desenvolvedor:

  • Um ponto de partida compreende o preâmbulo (clichê) em sua funcionalidade, a maioria das classes principais e pontos de acesso normalmente farão parte do clichê. Isso dá aos desenvolvedores um ponto de partida para a documentação
  • Expectativas sua colocação em desenvolvedores se tornará aparente, por exemplo, se você configurar um objeto de rastreamento como parte do preâmbulo, os desenvolvedores saberão onde registrar exceções e informações
  • Compreensão implícita ao forçar o desenvolvedor a passar pelo processo de instanciação de aulas, elas podem deduzir as técnicas necessárias para acessar o restante de sua biblioteca e ter a oportunidade de apresentá-las a qualquer convenção que você ' ve usado em toda a sua biblioteca
  • Fácil validação quando seu código clichê é necessário, geralmente pode ser validado com exceções e cláusulas de proteção, evitando que os consumidores fiquem muito mais presos quando você já está comprometido com um processo defeituoso
  • A Configuração de uma biblioteca que requer código clichê é fácil, pois já existe um ponto óbvio de implementação para customizar a funcionalidade para um único caminho de execução. Isso é particularmente útil se o código clichê exigido for aprimorado com o padrão Factory ou Command

Quando os consumidores da sua biblioteca têm controle sobre a instanciação, eles podem criar facilmente métodos privados / de extensão, classes pai ou até modelos para implementar o código clichê.

    
por 05.12.2014 / 12:56
fonte
-3

O único problema real com o código clichê é que quando você encontrar um bug nele, você precisa consertar todos os lugares em que você o usou, em vez do único lugar que você reutilizou .

    
por 14.05.2012 / 23:27
fonte