Melhor resposta
Sim, você vai escrever os mesmos tipos e pesquisas e funções de manipulação de string milhares de vezes, cada uma apenas uma pequena variação da última vez.
Isso é tão verdade que uma filosofia de economia de sanidade negando isso surgiu na academia chamada “Dont Repeat Yourself”, que finge que há uma maneira de não escrever o mesmo código e mais.
Esse mantra estúpido realmente precisa ser derrotado das pessoas.
Design inteligente significa não ter que começar do zero todas as vezes, e codificação inteligente significa saber quando escrever algo novo e quando reutilizar código.
A reutilização de código como uma medida de economia de tempo e depuração tem seus méritos, quando disponível. Isso evoluiu para ferramentas úteis, como genéricos e modelos e o conceito de herança e APIs universais para que a classificação e a pesquisa se tornem genéricas, em vez de precisar que uma nova função de pesquisa seja escrita para cada tipo de array ou lista.
A cópia do texto do código é considerada o pior erro porque copia bugs e incha o código, e é principalmente o que é considerado redundante.
É aqui que a herança brilha como uma estratégia de redução de código. As subclasses não precisam ser reescritas caras de suas classes base se a maior parte da funcionalidade comum a todas as subclasses for colocada na classe base. Muitas vezes, a subclasse pode chamar a função da classe base e então realizar algumas alterações ela mesma, em vez de reimplementar a função inteira. É disso que eles estão falando.
Mas o “Dont Repeat Yourself” ganhou status de cult em fóruns como este como uma forma ideal de codificar e projetar, e isso simplesmente não é verdade ou prático ou parte de qualquer grande corpo de código do mundo real.
O over-design é para desenvolvedores de linguagem, teóricos e criadores de framework. Os codificadores práticos apenas escrevem código que funciona, e se o seu programa tiver duas classes que implementam pesquisa binária, tudo bem. Você realmente precisa de uma terceira classe com subclasses para lidar com pesquisas binárias para as outras duas classes de dados? Talvez, mas se trata de escalar uma magnitude de classes de dados com a necessidade de pesquisa binária, então torna-se uma economia de tempo real e de bug para ter uma classe que faz isso corretamente que pode ser subclassificada para lidar com as necessidades das classes de dados. Viu?
Programar em grande escala exige muito mais planejamento e análise da divisão de trabalho do que programar pequenos trabalhos e ferramentas. Então, sim, se você tiver um projeto com mais de 1000 linhas de código, examine o design e encontre algoritmos e funções redundantes e decida se você pode reuni-los em uma única classe de utilitário funcional ou duas e compartilhar o código para todos os objetos de dados. Mas não faça disso uma busca religiosa para a eliminação final da redundância. E não acredite naqueles que acreditam.
Resposta
Se for a opção mais eficiente, então não é uma má prática. Fazer qualquer coisa que tenha uma solução mais simples e elegante disponível, é uma má prática .
Neste caso, um switch gigante pode frequentemente ser substituído por uma interface ou permitir que uma classe tenha sua própria responsabilidade, etc.
Por exemplo, se você tiver algo assim :
Isso funcionará. O código será meio robusto, contanto que os valores sejam apenas adicionados e não editados, e na verdade é até bastante eficiente, já que as comparações de bits levam tempo praticamente zero. Mas isso vai ficar fora de controle, difícil de navegar, e você já tem que definir essas classes de carro de qualquer maneira.
Em vez disso, vamos começar com algo como isto:
Novamente, provavelmente tínhamos isso de qualquer maneira, apenas sem o método numberOfCylinders, e agora nosso primeiro método tem a seguinte aparência:
Agora imagine por um momento que somos uma loja nacional de peças de automóveis, e temos literalmente milhares de carros de várias marcas, modelos, acabamentos, etc. Que se / então se tornasse um monstro enorme, impossível de ler, extremamente difícil de adicionar ou remover com segurança, etc.
Então, novamente , não é sempre uma prática ruim e, às vezes, precisaremos de uma grande mudança ou algo parecido, mas normalmente há uma maneira mais fácil de se esconder lá.
EDITAR: Há muitos comentários sobre ter um n número extremamente grande de combinações de carros (potencialmente milhões ao longo da história) e classes que implementam Car failing here. É claro que, em um determinado ponto, as classes não funcionarão e você armazenará arquivos simples em um banco de dados e usará um acessador.
Minha resposta pretendia mostrar a armadilha de usar muito tempo declarações condicionais, não como uma tentativa real de construir uma arquitetura de loja de peças automotivas.Se você trabalha em um grande varejista de automóveis, por favor, não tome minha resposta simples como a base de sua arquitetura de software 🙂