TL; DR: depende do que você está tentando resolver.
Eu tive uma conversa semelhante com o meu vovô sobre isso, enquanto estávamos falando sobre como Func e Ação no C # são incríveis. My Gramps é um programador temporizador muito antigo, que tem estado em torno de códigos-fonte desde que o software foi executado em computadores que levaram uma sala inteira.
Ele mudou de tecnologia várias vezes em sua vida. Ele escreveu o código em C, COBOL, Pascal, BASIC, Fortran, Smalltalk, Java e, eventualmente, iniciou o C # como hobby. Eu aprendi a programar com ele, sentado em seu colo enquanto eu era apenas um devling, esculpindo minhas primeiras linhas de código no editor azul do SideKick da IBM. Quando eu tinha 20 anos, eu já havia passado mais tempo codificando do que jogando do lado de fora.
Essas são algumas das minhas lembranças, então me desculpe se não sou exatamente prático ao recontá-las. Eu gosto um pouco desses momentos.
Foi o que ele me disse:
"Devemos ir para a generalização de um problema, ou resolvê-lo no escopo específico, você pergunta? Bem, isso é uma ... pergunta."
Gramps fez uma pausa para pensar sobre isso por um breve momento, enquanto corrigia a posição de seus óculos no rosto. Ele estava jogando um jogo match-3 em seu computador, enquanto ouvia um LP do Deep Purple em seu antigo sistema de som.
"Bem, isso dependeria do problema que você está tentando resolver", ele me disse. "É tentador acreditar que existe uma solução única e sagrada para todas as escolhas de design, mas não existe uma. A arquitetura de software é como o queijo, você vê."
"... queijo, vovô?"
"Não importa o que você pensa sobre o seu favorito, sempre haverá alguém que acha que é fedorento".
Eu pisquei em confusão por um momento, mas antes que eu pudesse dizer qualquer coisa, Gramps continuou.
"Quando você está construindo um carro, como você escolhe o material para uma peça?"
"Eu ... eu acho que depende dos custos envolvidos e do que a peça deve fazer, suponho."
"Depende do problema que a peça está tentando resolver. Você não vai fazer um pneu feito de aço, ou um pára-brisa feito de couro. Você escolhe o material que melhor resolve o problema que você tem em mãos. Agora, o que é uma solução genérica? Ou uma solução específica? Para qual problema, para qual caso de uso? Você deve ir com uma abordagem funcional completa, para dar flexibilidade máxima a um código que será usado apenas uma vez? código frágil para uma parte do seu sistema que vai ver muitos e muitos usos e, possivelmente, muitas mudanças? Opções de design como essas são como os materiais que você escolhe para uma peça em um carro ou a forma do tijolo Lego que você escolhe para construir uma pequena casa. Que tijolo de Lego é o melhor? "
O programador idoso pegou um pequeno modelo de trem Lego que ele tem em sua mesa antes de continuar.
"Você só pode responder que, se você sabe para o que você precisa desse bloco. Como você saberá se a solução específica é melhor que a genérica, ou vice-versa, se você nem sabe qual problema você está tentando resolver? Você não pode ver além de uma escolha que você não entende. "
".. Você acabou de citar The Matrix? "
"O que?"
"Nada, vá em frente."
"Bem, suponha que você esteja tentando criar algo para o Sistema Nacional de Faturas. Você sabe como é essa API infernal e seu arquivo XML de trinta mil linhas de dentro. Como uma solução 'genérica' para criar esse arquivo Seria parecido? O arquivo está cheio de parâmetros opcionais, cheio de casos que apenas ramos muito específicos de negócios devem usar. Para a maioria dos casos, você pode ignorá-los com segurança. Você não precisa criar um sistema de fatura genérico se o único Uma coisa que você vai vender é calçado, basta criar um sistema para vender sapatos e torná-lo o melhor sistema de faturamento de venda de sapatos. Agora, se você tivesse que criar um sistema de faturas para qualquer tipo de cliente, ampla aplicação - para ser revendida como um sistema de vendas independente e genérico, por exemplo - agora é interessante implementar as opções que são usadas apenas para gás, alimentos ou álcool. Agora esses são possíveis casos de uso. Antes de serem apenas alguns casos hipotéticos de Não use , um d você não deseja implementar os casos Não use . Não use é o irmão mais novo de Não precisa . "
Gramps colocar o trem lego de volta em seu lugar e voltou para seu jogo de combinar 3.
"Então, para escolher uma solução genérica ou específica para um determinado problema, primeiro você precisa entender qual é o problema. Caso contrário, você está apenas adivinhando e adivinhando é o trabalho dos gerentes, não dos programadores. Como quase tudo em TI, isso depende ".
Então, você tem isso. "Depende". Essa é provavelmente a expressão de duas palavras mais poderosa quando se pensa em design de software.