Os princípios SOLID e KISS / YAGNI são opostos próximos do polar. Alguém lhe dirá que se doSomething () não puder ser justificado como parte integrante do job que a classe que está chamando, ele deve estar em uma classe diferente que é fracamente acoplada e injetada. O outro lhe dirá que, se este é o único lugar em que doSomething é usado, até mesmo extraí-lo em um método pode ter sido um exagero.
Isto é o que faz com que bons programadores valham seu peso em ouro. A estrutura "adequada" é uma base caso a caso, exigindo conhecimento da base de código atual, do caminho futuro do programa e das necessidades do negócio por trás do programa.
Eu gosto de seguir esta metodologia simples de três etapas.
- Na primeira passagem, faça funcionar.
- Na segunda passagem, limpe-a.
- Na terceira passagem, torne-a SOLID.
Basicamente, é assim que você mistura o KISS com o SOLID. Quando você escreve uma linha de código pela primeira vez, por tudo o que você sabe, será uma única vez; simplesmente tem que trabalhar e ninguém se importa como, então não fique chique. Na segunda vez que você coloca o cursor nessa linha de código, você refutou sua hipótese original; Ao revisitar esse código, é provável que você o estenda ou o conecte de algum outro lugar. Agora, você deve limpá-lo um pouco; extraia métodos para informações mais usadas, reduza ou elimine a codificação de copiar / colar, adicione alguns comentários, etc. Na terceira vez que você voltar a esse código, agora é uma grande interseção para os caminhos de execução do seu programa. Agora você deve tratá-lo como parte essencial de seu programa e aplicar as regras do SOLID sempre que possível.
Exemplo: você precisa escrever uma linha simples de texto no console. A primeira vez que isso acontece, o Console.WriteLine () é bom. Em seguida, você retorna a esse código depois que novos requisitos também determinam a gravação da mesma linha em um log de saída. Neste exemplo simples, pode não haver muito código "copiar / colar" repetitivo (ou talvez exista), mas ainda é possível fazer algumas limpezas básicas, talvez extrair um método ou dois para evitar a inclusão de operações de E / S em lógica de negócios mais profunda . Então, você volta quando o cliente quer a mesma saída de texto para um pipe nomeado para um servidor de monitoramento. Agora, essa rotina de saída é um grande negócio; você está transmitindo o mesmo texto de três maneiras. Este é o exemplo de livro didático de um algoritmo que se beneficiaria de um padrão Composite; desenvolver uma interface IWriter simples com um método Write (), implementar essa interface para criar classes ConsoleWriter, FileWriter e NamedPipeWriter, e mais uma vez criar uma classe composta "MultiWriter", expor uma dependência IWriter em sua classe, configurar o MultiWriter compósito com os três escritores reais, e ligá-lo. Agora, é bastante sólido; a partir daí, sempre que os requisitos determinarem que a saída deve ir a qualquer lugar novo, basta criar um novo IWriter e conectá-lo ao MultiWriter, sem necessidade de tocar em nenhum código de trabalho existente.