Princípios SÓLIDOS vs YAGNI

41

Quando os princípios do SOLID se tornam YAGNI?

Como programadores, fazemos concessões o tempo todo, entre complexidade, facilidade de manutenção, tempo para construir e assim por diante. Entre outros, duas das diretrizes mais inteligentes para fazer escolhas são, na minha opinião, os princípios do SOLID e YAGNI. Se você não precisa disso; não construa e mantenha limpo.

Agora, por exemplo, quando assisto à série dimecast no SOLID , vejo que começa como um programa bastante simples, e termina como um programa bastante complexo (o final sim, a complexidade também está nos olhos de quem vê), mas ainda me faz pensar: quando os princípios do SOLID se transformam em algo que você não precisa? Todos os princípios sólidos são formas de trabalhar que permitem o uso para fazer mudanças em um estágio posterior. Mas e se o problema a resolver for bem simples e for um aplicativo descartável, e depois? Ou os princípios do SOLID são sempre aplicáveis?

Como solicitado nos comentários:

por KeesDijk 30.12.2010 / 15:48
fonte

7 respostas

50

É sempre difícil julgar uma abordagem baseada em um screencast, já que os problemas escolhidos para demonstrações são normalmente tão pequenos que a aplicação de princípios como o SOLID rapidamente faz com que pareça que a solução é completamente overengineered.

Eu diria que os princípios do SOLID são quase sempre úteis. Uma vez que você se torne proficiente com eles, usá-los não parece algo que você tenha que pensar deliberadamente. Isso só se torna natural. Eu vi muitos aplicativos descartáveis serem mais do que isso, então agora eu tenho medo de dizer que vou jogar algo fora, porque você nunca sabe.

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

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

    
por 30.12.2010 / 15:55
fonte
19

Pense no problema em primeiro lugar. Se você aplicar cegamente os princípios de YAGNI ou SOLID, poderá se machucar mais tarde. Algo que eu espero que todos possamos entender é que não existe uma abordagem de projeto "um" que se encaixe em todos os problemas. Você pode ver evidências de que, quando uma loja vende um chapéu anunciado como "tamanho único para todos", não cabe na 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 deles está preocupado com a arquitetura do seu aplicativo e o outro está preocupado com o processo de desenvolvimento como um todo. Embora possa haver sobreposição em alguns casos, eles são problemas distintos.

YAGNI (Você não vai precisar [acrônimo americano]) preocupa-se em economizar tempo de desenvolvedor adicionando fundações de concreto reforçadas com aço a uma ponte que tem a intenção de abranger um riacho de 3 pés de largura quando uma ponte de madeira mais simples vai fazer tudo certo. Se estivermos atravessando um rio de uma milha de largura e precisando suportar vários reboques de trator, é claro que precisaríamos de um trabalho de fundação extra. Em essência, a YAGNI está lhe dizendo para olhar a foto e o design maiores para as necessidades atuais . É abordar 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 nos certificamos de que as peças da ponte se encaixam corretamente e podem ser mantidas com o tempo. Você pode aplicar os princípios do SOLID à ponte de madeira, bem como à ponte de concreto reforçada com aço.

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

    
por 30.12.2010 / 16:45
fonte
9

Princípios sólidos não são necessários quando se trata de um aplicativo descartável; caso contrário, são sempre necessários.

SOLID e YAGNI não estão em desacordo: O bom design de classe torna a aplicação mais fácil de manter. YAGNI apenas afirma 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 realmente precise.

É a diferença entre uma classe Car que tem limites bem definidos (SOLID) e uma classe de carro que tem a capacidade de auto-cura (YAGNI) antes que o cliente peça por ela.

    
por 30.12.2010 / 15:54
fonte
3

Nada sempre se aplica! Não deixe Arquitetura de Astronautas Assustar você! O importante é tentar entender os problemas que esses princípios estão tentando resolver, para que você possa tomar uma decisão informada sobre como aplicá-los.

Recentemente, tentei entender quando deveria usar o Princípio de responsabilidade única ( aqui está o que eu criei.)

Espero que isso ajude!

    
por 30.12.2010 / 16:18
fonte
2

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

“Everything should be made as simple as possible, but no simpler.”

E isso é mais ou menos a abordagem que eu tomo quando confrontado com a troca SOLID vs YAGNI: aplique-os alternativamente, porque você nunca sabe se um programa é um 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é que você converge para o nível correto de entropia. Esperançosamente.

    
por 09.01.2015 / 15:01
fonte
1

Existem muitas maneiras de projetar um programa para um determinado problema; 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 de recursos. 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 um código que é mais difícil de entender e manter, mas que não oferece nenhum valor agregado.

Um programa 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á trade-off, apenas dois eixos ortogonais no espaço de decisão. Um programa ideal é modular e possui apenas recursos essenciais.

    
por 09.01.2015 / 15:27
fonte
0

Acho que você deve começar a YAGNI e, sempre que houver necessidade, SOLIDIFICAR isso.

O que eu quero dizer é que o SOLID está lá, então quando você adicionar uma nova classe você não precisará refatorar, simplesmente mude uma implementação (por exemplo), na minha opinião, escreva seu código simplesmente, e quando você ver que você está mudando as coisas - mude isso com SOLID (ou seja, a refatoração temida que o SOLID deve salvar você - 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 forma (no começo) e onde quer que seja necessário, seu código é legal e arrumado.

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

    
por 05.08.2016 / 07:16
fonte