Programando Princípios SOLID

Eu estava no seu lugar há alguns meses até encontrar um artigo muito útil.

Cada princípio é bem explicado com situações do mundo real que cada desenvolvedor de software pode enfrentar em seus projetos. Eu estou cortando curto aqui e apontando para a referência - S.O.L.I.D. Desenvolvimento de software, um passo de cada vez .

Como apontado nos comentários, há outra ótima leitura em pdf - Software SOLID da Pablo Desenvolvimento .

Além disso, há alguns bons livros que descrevem os princípios do SOLID em mais detalhes - Good Book on SOLID Software Development .

Editar e comentários de um breve resumo para cada princípio:

• “S” - O princípio da responsabilidade única é impulsionado pelas necessidades do negócio para permitir mudanças. “Um único motivo para mudar” ajuda você a entender quais conceitos separados logicamente devem ser agrupados considerando o conceito e o contexto do negócio, em vez do conceito técnico sozinho. In another words , aprendi que cada classe deve ter uma única responsabilidade. A responsabilidade é apenas realizar a tarefa atribuída

• “O” - Aprendi Open Closed Principle e comecei a "preferir composição sobre herança" e, como tal, preferir classes que não possuem métodos virtuais e são possivelmente seladas, mas dependem de abstrações para sua extensão.

• "L" - Aprendi o Princípio de Substituição de Liskov com a ajuda do padrão Repositório para gerenciar o acesso a dados.

• “I” - Aprendi sobre o Princípio de Segregação de Interface aprendendo que os clientes não devem ser forçados a implementar interfaces que não usam (como no Provedor de Associação no ASP.NET 2.0). Então interface não deveria ter “muitas responsabilidades”
• “D” - Aprendi sobre o Princípio de Inversão de Dependência e comecei a codificar que é fácil mudar . Mais fácil de mudar significa um custo total de propriedade mais baixo e maior facilidade de manutenção.

Como um recurso útil do CodePlex foi mencionado nos comentários, a referência está incluída no SOLID pelo exemplo

(I) nterface Segregação e (D) ependência A inversão pode ser aprendida através de testes unitários e zombaria. Se as classes criarem suas próprias dependências, você não poderá criar bons testes de unidade. Se eles dependem de uma interface muito ampla (ou nenhuma interface), não é muito óbvio o que precisa ser ridicularizado para fazer seus testes unitários.

Princípio de Substituição de Liskov basicamente não permite que você use a herança de implementação em excesso: você nunca deve usar herança apenas para reutilização de código (existe uma composição para isso)! Ao aderir ao LSP, você pode ter certeza de que existe realmente um "relacionamento" entre sua superclasse e sua subclasse.

O que ele diz é que suas subclasses devem implementar todos os métodos da subclasse de maneira semelhante à implementação dos métodos na subclasse. Você nunca deve sobrescrever um método com a implementação de NOP ou retornar null quando o supertipo lança uma exceção; declarado em termos de design por contrato, você deve respeitar o contrato do método da superclasse ao substituir um método. Uma maneira de se defender contra a quebra desse princípio é nunca sobrepor um método implementado; em vez disso, extraia uma interface e implemente essa interface em ambas as classes.

Princípio de Segregação de Interface , Princípio de Responsabilidade Única e Princípio de Alta Coesão do GRASP estão de alguma forma relacionados; eles se referem ao fato de que uma entidade deve ser responsável por apenas uma coisa, de modo que haja apenas uma razão para a mudança, de modo que a mudança seja feita com muita facilidade.

Na verdade, diz que se uma classe implementa uma interface, ela deve implementar e usar todos os métodos da interface. Se houver métodos que não são necessários nessa classe específica, a interface não é boa e deve ser dividida em duas interfaces, uma que tenha apenas os métodos necessários para a classe original. Pode ser considerado a partir de um POV, que se relaciona com o princípio anterior pelo fato de que ele não permite criar grandes interfaces para que sua implementação possa quebrar o LSP.

Você pode ver Inversão de Dependência no Padrão de Fábrica; aqui tanto o componente de alto nível (o cliente) quanto o componente de baixo nível (instância individual a ser criada) dependem da abstração ( a interface). Uma maneira de aplicá-lo em uma arquitetura em camadas: você não deve definir uma interface para uma camada na camada que é implementada, mas no módulo que é chamado. Por exemplo, a API para a camada de origem de dados não deve ser gravada na camada de fonte de dados, mas na camada de lógica de negócios, onde é necessário ser chamado. Desta forma, a camada da fonte de dados herda / depende do comportamento definido na lógica de negócio (portanto, a inversão) e não vice-versa (como seria normal). Isso fornece flexibilidade no design, permitindo que a lógica de negócios funcione sem qualquer alteração de código, com outra fonte de dados totalmente diferente.