Princípios do SOLID vs YAGNI


43

Quando os princípios do SOLID se tornam YAGNI?

Como programadores, fazemos trocas o tempo todo, entre complexidade, manutenção, tempo para construir e assim por diante. Entre outras, duas das diretrizes mais inteligentes para fazer escolhas estão em minha mente os princípios do SOLID e o YAGNI. Se você não precisar; não construa e mantenha-o limpo.

Agora, por exemplo, quando assisto a série dimecast no SOLID , vejo que ele começa como um programa bastante simples e acaba sendo um programa bastante complexo (final, a complexidade sim também está nos olhos de quem vê), mas ainda faz me pergunto: quando os princípios do SOLID se transformam em algo que você não precisa? Todos os princípios sólidos são maneiras de trabalhar que permitem o uso para fazer alterações posteriormente. Mas e se o problema a ser resolvido for bem simples e for um aplicativo descartável, e daí? Ou os princípios do SOLID são algo que sempre se aplica?

Conforme solicitado nos comentários:


Também não deveria ser o título SOLID principle vs YAGNI?
Lobo

2
@Wolf: É um plural "SOLID (responsabilidade única, aberto e fechado, substituição de Liskov, segregação de interface e inversão de dependência) é um acrônimo mnemônico introduzido por Michael Feathers para os" cinco primeiros princípios "nomeados por Robert C. Martin no início Anos 2000, que representa cinco princípios básicos de programação e design orientados a objetos ".
logC

Respostas:


55

É sempre difícil julgar uma abordagem com base em um screencast, já que os problemas escolhidos para as demos são geralmente tão pequenos que a aplicação de princípios como o SOLID faz com que pareça que a solução está completamente com excesso de engenharia.

Eu diria que os princípios do SOLID são quase sempre úteis. Depois de se tornar proficiente com eles, usá-los não parece ser algo em que você tenha que pensar deliberadamente. Apenas se torna natural. Eu já vi muitos aplicativos descartáveis ​​descartáveis ​​se tornarem mais do que isso, então agora tenho medo de dizer que vou jogar algo fora, porque você nunca sabe.

A abordagem que eu costumo adotar é que, se estou escrevendo um aplicativo simples para uma tarefa específica, algumas vezes renuncio a princípios de grandes nomes em favor de algumas linhas de código que funcionam. Se eu achar que estou voltando ao aplicativo para fazer mais alterações, levarei um tempo para torná-lo sólido (pelo menos um pouco, pois uma aplicação de 100% dos princípios raramente é viável).

Em aplicativos maiores, começo pequeno e, à medida que o programa evolui, aplico os princípios do SOLID sempre que possível. Dessa forma, não tento projetar a coisa toda de antemão até o último enum. Esse, para mim, é o ponto ideal onde YAGNI e SOLID coexistem.


Isso é basicamente o que eu acho também. Como uma observação que não julgo pelo screencast, apenas acho que é um bom exemplo de como o software pode crescer ao aplicar o SOLID.
KeesDijk

Bom ponto. Qualquer demonstração será distorcida para demonstrar ou exacerbar o problema em questão. Essencialmente, é toda a ideia de levar uma idéia à sua conclusão mais completa para provar que é uma falácia. Uma premissa que por si só pode ser abusada.
Berin Loritsch

YAGNI and SOLID coexistboa conclusão. Embora possa ser um bom ponto de partida
Lobo

Parece que às vezes é necessário um palpite. Você precisa saber onde pode começar a ver muitas alterações para saber onde seus níveis de abstração versus o encanamento param e começam.
9139 johnny

19

Pense sobre o problema em primeiro lugar. Se você aplicar cegamente os princípios de YAGNI ou SOLID, poderá se machucar mais tarde. Algo que espero que todos possamos entender é que não existe uma abordagem de design "única" que atenda a todos os problemas. Você pode ver evidências disso quando uma loja vende um chapéu anunciado como "tamanho único", mas não combina com sua cabeça. É muito grande ou muito pequeno.

Em vez disso, é melhor entender os princípios e problemas que o SOLID está tentando resolver; bem como os princípios e problemas que a YAGNI está tentando resolver. Você verá que um se preocupa com a arquitetura do seu aplicativo e o outro se preocupa com o processo de desenvolvimento como um todo. Embora possa haver sobreposição em alguns casos, eles são problemas distintos.

A YAGNI (você não vai precisar disso) quer economizar tempo do desenvolvedor, adicionando fundações de concreto reforçado com aço a uma ponte que se destina apenas a atravessar um riacho de 3 pés de largura quando uma ponte de madeira mais simples bem. Se estamos atravessando um rio de uma milha de largura e precisando suportar vários reboques de tratores, é claro que precisaríamos desse trabalho extra de fundação. Em essência, a YAGNI está dizendo para você olhar para a imagem maior e o design para as necessidades atuais . Está abordando o problema de tornar algo muito complicado, porque estamos antecipando uma série de necessidades potenciais que o cliente ainda não identificou.

O SOLID se preocupa com a forma como garantimos que as peças da ponte se encaixem corretamente e possam ser mantidas com o tempo. Você pode aplicar os princípios do SOLID à ponte de madeira e à ponte de concreto armado de aço.

Em suma, esses dois conceitos não estão necessariamente em conflito entre si. Quando você se deparar com uma situação em que acredita estar, é hora de dar uma olhada no quadro geral. Dependendo da sua conclusão, você pode decidir acabar com uma parte dos princípios do SOLID ou pode realmente precisar.


Sim, concordo .. não existe uma abordagem de bala de prata que se adapte a todos os cenários.
EL Yusubov

O seu não make sure the pieces of the bridge fit togetheré de longe tão evidente quanto can be maintained over time.
Wolf

Basicamente, o SOLID é o que permitirá que você transforme essa ponte de madeira em uma ponte de aço completa em uma milha de comprimento, capaz de suportar um pelotão blindado sem reescrever completamente ou simplesmente usando hack após hack.
Sara

@ Kai, essa é uma premissa falsa. Se você precisa de uma ponte que mede 1 milha, então cria uma ponte que mede 1 milha. Se você precisa de uma ponte que mede 5 pés, você constrói uma ponte que mede 5 pés. Não me interpretem mal, os princípios do SOLID são muito úteis, mas é preciso mais compreensão deles para saber quais princípios não são necessários para o problema em questão. 9 vezes em 10, essa milha extra nunca é necessária.
Berin Loritsch

@BerinLoritsch, e é por isso que eu concordo que, se você precisa de 5 pés, você constrói 5 pés, mas você NÃO constrói 5 pés ducttaping dois 2x4s no chão. você faz o que precisa e faz bem. (embora a analogia é um tipo de desmoronando)
sara

9

Os princípios do SOLID não são necessários quando se trata de um aplicativo descartável; caso contrário, eles são sempre necessários.

O SOLID e o YAGNI não estão em desacordo: um bom design de classe facilita a manutenção do aplicativo. YAGNI apenas declara que você não deve adicionar a capacidade de seu aplicativo ser essa monstruosidade configurável que pode fazer tudo sob o sol - a menos que ele realmente precise.

É a diferença entre uma classe Car que possui limites bem definidos (SOLID) e uma classe de carro com capacidade de auto-recuperação (YAGNI) antes que o cliente solicite.


1
Isso não está confuso? O que há sobre isso: aplique adequadamente os princípios do SOLID para lidar com a complexidade dos carros que se recuperam automaticamente ou aplique o YAGNI, desde que seus carros ainda sejam tão simples que nunca quebrem (ou - como alternativa - tão irritados que podem ser jogados fora) .
Wolf

2
@ Wolf, os princípios do SOLID não dizem o que você deve fazer, apenas COMO. se você já decidiu que deseja carros auto-reparáveis, poderá aplicar os princípios do SOLID a esse código. O SOLID não diz se um carro auto-reparável é ou não uma boa ideia. É aí que YAGNI entra.
sara

Muitas vezes, os aplicativos descartáveis ​​não são.
Tulains Córdova

"Auto-cura" é bom. "Antes que o cliente peça," também é bom porque acho que toda a idéia, se você ouvir o tio Bob, é de lugares que geram lucro e antecipam as necessidades do cliente e que têm um negócio viável que pode responder às necessidades porque eles mudam. Muitas pessoas se incomodam com o tio Bob porque ele não está certo com a programação, mas ele está lhe dizendo, na maioria das vezes, por que é importante usar o SOLID, não apenas como.
johnny

"Os princípios do SOLID não são necessários quando se trata de um aplicativo descartável" . Eu acho que os princípios do SOLID são um bom hábito; portanto, mesmo que seja um aplicativo descartável, você está treinando para quando precisa escrever um aplicativo grande, para que possa haver um benefício em seguir os princípios do SOLID.
Icc97 5/05

4

Nada sempre se aplica! Não deixe que os astronautas da arquitetura assustem você! O importante é tentar entender quais problemas esses princípios estão tentando resolver para que você possa tomar uma decisão informada sobre sua aplicação.

Recentemente, eu estava tentando entender quando deveria usar o Princípio de Responsabilidade Única ( eis o que eu criei).

Espero que isto ajude!


2

Há uma citação atribuída a Einstein (provavelmente uma variação de uma real ):

"Tudo deve ser feito o mais simples possível, mas não mais simples."

E essa é mais ou menos a abordagem adotada quando confrontada com o trade-on do SOLID vs YAGNI: aplique-os alternativamente, porque você nunca sabe se um programa é código 'descartável' ou não. Então, basta adicionar uma camada de sujeira que funcione, depois polir para uma interface mais limpa ... e repetir até convergir para o nível certo de entropia. Esperançosamente.


Bom ponto: you never know if a program is 'throw-away' code- bem, acho que a ideia alternativa não é tão boa.
Wolf

@ Wolf: sim, eu estava expandindo na ordem dos passos que considero melhores (resumidos no slogan 'Primeiro torne possível, depois torne bonito e rápido'), mas depois pensei ... YAGNI :)
logc

1

Existem várias maneiras de criar um programa para um determinado problema; O SOLID é uma tentativa de identificar as propriedades de um bom design. O uso adequado do SOLID deve resultar em um programa mais fácil de raciocinar e modificar.

YAGNI e KISS estão preocupados com o escopo do recurso. Um programa que resolve mais tipos de problemas é mais complexo e abstrato. Se você não precisa dessa generalidade, gastou tempo e esforço criando código mais difícil de entender e manter, mas não oferece valor agregado.

Um programa que foi bem projetado não é necessariamente focado apenas nos recursos necessários. Um programa focado apenas nos recursos necessários não é necessariamente bem projetado. Não há compromisso, apenas dois eixos ortogonais no espaço de tomada de decisão. Um programa ideal é modular e possui apenas recursos essenciais.


0

Eu acho que você deve iniciar o YAGNI e, sempre que houver necessidade, SOLIDify.

O que eu quero dizer é que o SOLID está lá. Portanto, quando você adiciona uma nova classe, não precisa refatorar, basta alternar uma implementação (por exemplo), bem, na minha opinião, escreva seu código com simplicidade e quando perceber que está mudando coisas - altere-o com o SOLID (isto é, a refatoração temida do SOLID deve salvá-lo - não é tão ruim quando você está apenas começando).

Você não está perdendo tempo, porque teria que fazer o trabalho de qualquer maneira (no início) e onde for necessário, o código é agradável e arrumado.

Eu acho que você poderia chamar de avaliação preguiçosa do SOLID.


Hum, eu vejo o seu ponto de vista sobre a postagem ser redundante, eu a excluí, mas parece que não tenho privilégios para fazê-lo (ou não estou vendo o botão). De qualquer forma, vou editá-lo para ficar mais claro.
Binyamin #
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.