Executando verificação de segurança...
Em resposta a Arquitetura de Software em C# no Mundo Real: Capítulo 11 – Mitos e Más Interpretações na Arquitetura .NET
5
oL3gn4

Escreve if/else encadeado onde um Strategy resolveria com elegância.

Não entendo esse necessidade de deixar o código elegante. Para mim, código tem que ser simples e manutenível. Se um júnior cabaço olha um código elegante e não sabe o que fazer, seu código não foi bem escrito.
Sei que o post não é sobre isso, mas quis trazer esse ponto. Concordando com sua conslusão, que se resume muito bem quando diz:

O resultado disso tudo é sempre o mesmo:
Código difícil de entender, difícil de evoluir, e impossível de explicar.

Carregando publicação patrocinada...
1
carubbi

A questão não é sobre “deixar o código elegante” no sentido estético ou sofisticado. É sobre deixar ele preparado pra mudar sem virar um campo minado.

No caso do Strategy, a ideia é simples: quando surge um novo cenário, você adiciona uma nova classe. Não precisa tocar nas outras. Não precisa abrir aquele if/else gigante, nem arriscar quebrar o comportamento de casos que já funcionam.

Já com if/else, toda vez que aparece uma nova variação, você tem que entrar no mesmo bloco de código, mexer num switch que cresce, revisar dependências… e esse acoplamento vai só piorando.

E isso afeta diretamente a manutenção.
Inclusive pro júnior que você citou — porque ele vai entender muito melhor um código separado por responsabilidade clara, do que um monolito de if/else que tenta cobrir todos os cenários.

Código simples e manutenível não significa “tudo em um lugar só”.
Significa “fácil de entender, mudar e testar sem medo”.

Valeu demais por levantar o ponto e contribuir com a discussão. É esse tipo de troca que melhora o código e a cabeça da galera. 👊🏼

4
oL3gn4
  • Autor
    Autor

Dificilmente um desenvolvedor júnior em início de carreira vai entender ou saber quando aplicar padrões de projeto. A leitura de um simples if/else é, de fato, muito mais direta do que ter que navegar por várias classes em um projeto extenso.

Infelizmente, é comum ver desenvolvedores implementando padrões complexos sem necessidade, muitas vezes para inflar o próprio ego. Eles tentam prever o futuro da aplicação, ignorando princípios mais relevantes como YAGNI e KISS. Muitas implementações nascem com a justificativa de que "no futuro poderemos precisar disso", o que leva à adoção desnecessária de padrões.

Eu mesmo já vi situações extremas, como a criação de uma factory para instanciar um command, mesmo quando havia apenas um único tipo de retorno, ou o uso de strategy para resolver o que poderia ser um simples if. Isso acontece, em parte, porque muitos artigos e tutoriais abordam esses temas de forma superficial, com exemplos rasos. Um desenvolvedor iniciante, então, acaba acreditando que essas implementações são regras absolutas, carregando essa ideia para sua carreira.

A chave é entender que padrões de projeto são ferramentas para resolver problemas específicos, não um fim em si mesmos. A simplicidade e a funcionalidade devem sempre vir em primeiro lugar.

1
carubbi

De fato. Não existe bala de prata, e tentar prever o futuro inteiro da aplicação quase sempre leva a overengineering.
Mas vale pensar também pela ótica dos testes: cada if novo que você adiciona duplica a quantidade de caminhos que precisam ser cobertos. A complexidade ciclomatica cresce rápido, e logo aquele método “simples” vira um Frankenstein cheio de exceções e casos especiais.
Quando você separa o comportamento em classes isoladas (via Strategy, por exemplo), cada cenário pode ser testado de forma independente, sem precisar montar todo o estado global do mundo pra testar um único fluxo.
No fim, o bom senso de quando aplicar o quê vem mesmo com a experiência. A gente erra forçando padrão onde não precisa, e também erra mantendo tudo junto por medo de complicar.
O ponto é: não dá pra nivelar por baixo.
Buscar simplicidade não pode virar desculpa pra empilhar if até ninguém mais querer mexer no código.