SOLID – OCP e Extension Methods

Extension Method é um recurso presente desde o C# 3.0 e que facilita bastante o uso do OCP – Open Closed Principle.

SOLID - Teoria e Prática

Os extension methods permitem que você adicione comportamentos em classes existentes sem precisar modificá-las. Os extension methods são um tipo especial de método estático, porém são chamados como se fossem métodos de instância na classe estendida.

Para o código escrito em .NET não há nenhuma diferença entre chamar um extension method ou os métodos realmente definidos em uma classe.

Como um recurso tão importante como este pode passar desconhecido por diversos desenvolvedores? É por este motivo que escrevi este artigo.

No SOLID os extension methods são perfeitos para aplicar OCP – Open Closed Principle de uma forma muito natural e proporcionando um código de baixo acoplamento.
Caso você não conheça todos os princípios do SOLID assista este tutorial completo.

Para demonstrar mais facilmente como utilizar os extension methods e aplicá-los ao OCP eu gravei um vídeo de 18 minutos onde rapidamente explico tudo.

* Assine meu canal no Youtube 🙂

O código fonte desta solução está disponível no GitHub

Referências


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

Desacoplando o ASP.NET Identity do MVC e Domínio

O ASP.NET Identity é uma ótima solução para a gestão dos usuários em sua aplicação, porém seu design é diretamente acoplado ao ASP.NET MVC e também devemos evitar de utilizar suas referências no domínio da aplicação.

Desacoplando o ASP.NET Identity. Finalmente após muitos pedidos eu consegui colocar a mão na massa e desenvolver um projeto modelo para ser usado como referência.

Desacoplando o ASP.NET Identity do MVC e Domínio

Como sabemos o ASP.NET Identity depende diretamente do EF (ou outros), Owin e System.Web, logo todas as implementações do ASP.NET Identity ficam de alguma forma acopladas em nossa camada de apresentação. Quando possuímos uma aplicação onde o usuário é uma peça importante no negócio existe a necessidade de representá-lo na camada de domínio, porém é altamente recomendado que a camada de domínio não conheça tecnologias terceiras (Identity, EF, outros).

Como resolver esse problema?

Foi após alguns estudos que cheguei no modelo que considero ser a “melhor abstração possível”, pois para o ASP.NET Identity funcionar na camada de apresentação é obrigatório levar algumas dependências, porém desde que esteja isolado em outra camada já conseguiremos ótimas boas vantagens.

Aviso: Caso você não conheça o ASP.NET Identity, DDD e Injeção de dependência sugiro que comece pelos tutoriais:

Neste tutorial você encontrará as seguintes tecnologias utilizadas

  • ASP.NET MVC 5
  • ASP.NET Identity 2
  • Entity Framework 6
  • Fluent API
  • Injeção de Dependência com Simple Injector
  • Owin
  • RestSharp para implementação do Twilio API (SMS)

Existem dois grandes objetivos nesta proposta, o primeiro objetivo é a reutilização, pois com um uma única solução (camada) de gestão de usuários é possível atender N aplicações, facilitando o gerenciamento e manutenção.

O segundo objetivo é permitir que a camada de domínio represente o usuário de forma abstraída, logo não existe referência direta do IdentityUser no domínio, porém é possível consultar os dados de usuário e incluir / modificar as informações salvas.

O primeiro passo é abstrair tudo, mover as dependências do Identity para uma camada isolada, depois injetar no MVC os objetos necessários, para essa implementação eu utilizei o Simple Injector, que como o próprio nome diz, é bem simples, rápido e atendeu bem a necessidade.

Com o Identity isolado e injetado devidamente na camada de apresentação (MVC) basta criar uma camada de acesso a dados que irá fornecer meios do domínio consumir dados do usuário de forma abstraída. A grande sacada está no uso correto do Fluent API e claro muita injeção de dependência.

A solução desde modelo não visa atender completamente a filosofia do DDD, pois procurei simplificar o bastante para deixar simples de modificar, por exemplo adicionando uma camada de Application. Portanto quem utilizar esta arquitetura deve estar ciente que algumas coisas a mais ainda precisam ser feitas.

Gostaria de ressaltar também que o template de projeto ASP.NET MVC que o Visual Studio fornece possui vários problemas de design de código. As controllers de Account e Manage do usuário precisaram ser parcialmente re-escritas para atender a injeção do Identity, problemas como mais de um construtor público e utilização do pattern (ou anti pattern?) Service Locator foram encontrados e retirados.

Para quem quiser acompanhar em detalhes técnicos toda a implementação dessa solução eu preparei o vídeo a seguir.

* Assine meu canal no Youtube 🙂

O código fonte desta solução está disponível no GitHub, caso queira propor alguma melhoria faça um Pull Request, será muito bem recebido.


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações Web com arquitetura baseada em DDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade inscreva-se em meu curso:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

Vamos precisar reescrever essa aplicação do zero.

Quem nunca disse ou ouviu isso? Vamos entender os motivos por trás dessa icônica frase.

Vamos precisar reescrever essa aplicação do zero! É a frase de rendição, é sinal que as coisas foram para o caminho errado. Dias, meses, anos de desenvolvimento que serão jogados fora por falta de um bom planejamento.

Vamos precisar reescrever essa aplicação do zero.

Quando chegamos nessa situação geralmente estamos diante de alguns dos cenários a seguir:

  • A tecnologia da aplicação é antiga demais e os novos recursos demandam mais tecnologia.
  • A arquitetura da aplicação é uma engenhoca complexa e sem sentido.
  • Devido a diversas implementações e manutenções do passado feitas de forma irresponsável ou sem padrão a aplicação se tornou a famosa “colcha de retalhos”, qualquer tipo de mudança é sofrível e demorada.
  • A cada mudança surgem diversos bugs em todas as partes da aplicação, pois existe muito acoplamento entre suas divisões, “tudo está acoplado com tudo”.
  • O time que trabalha na aplicação atualmente não concorda com a forma com que foi escrita e não está satisfeito em trabalhar nela.

Algumas situações muitas vezes não possuem uma escapatória, por exemplo o envelhecimento natural da aplicação. É muito caro manter uma aplicação sempre alinhada com a última versão da tecnologia, logo, algumas vezes prefere-se optar por saltos (atualizar a cada X tempo) ou simplesmente reescreve-la depois de alguns anos.

O cenário de envelhecimento da aplicação é um dos menores, geralmente a aplicação morre muito antes da hora. Eu trabalhei em uma empresa onde assisti a mesma aplicação ser reescrita 1 vez ao ano durante 3 anos. O que ocorre de tão errado assim?

Existem muitos motivos para tudo dar errado:

  • Equipe tecnicamente despreparada.
  • Falta de um líder técnico ou arquiteto que conduza o time e evite a deformação da aplicação.
  • Escopo mal planejado, falta de entendimento da entrega.
  • Prazo mal calculado.
  • Falta de visão. Típico caso do sisteminha de cadastro que virou um “ERP”.
  • Gestor de equipe que pula etapas e/ou não valoriza (não conhece) boas práticas, impondo uma metodologia que funciona apenas na teoria dele.

Motivos para dar errado são muitos, fazer software da forma correta é infinitamente mais complexo que simplesmente entregar software. É necessário ter uma boa equipe, um bom líder e um bom gestor.

Software é um bem durável assim como uma TV, Geladeira ou Carro, paga-se muito caro para desenvolve-lo e muito caro para mante-lo. A diferença é que o software precisa ser flexível e adaptar-se às constantes mudanças de escopo, logo não pode possuir uma engenharia fechada como uma TV e geralmente é ai onde mora a maioria dos problemas.

Para garantir um bom funcionamento da aplicação de forma que ela se adapte às diversas mudanças de escopo com o mínimo de esforço necessário e sem gerar outros problemas secundários, é preciso projetar a aplicação, não basta simplesmente escrever a aplicação e entregar.

Alguns pontos importantes devem sempre ser abordados:

Processo

Processo de desenvolvimento de software é um tema extenso demais, portanto deixarei apenas alguns pontos em destaque que devem ser levados bastante em consideração.

Processo de desenvolvimento de software é um processo diferente de outros, porém infelizmente ainda existem gestores que imaginam que desenvolver uma aplicação é o mesmo que construir um prédio, um navio ou um avião.

Durante a construção de um prédio com a obra em estágio avançado é praticamente impossível aplicar mudanças que mudam o aspecto do projeto, existe uma engenharia fechada e projetada para ser daquela forma, qualquer mudança poderia impactar em ter que iniciar novamente do zero.

Uma aplicação bem projetada deve ser flexível e estar aberta para mudanças de escopo com menor esforço necessário, portanto não devemos nos apegar em simplesmente entregar o que foi inicialmente levantado.

Uma das formas mais práticas de atender a necessidade do cliente é a entrega contínua, releases parciais para acompanhamento e feedback do cliente, é muito mais fácil ajustar uma mudança de escopo com a aplicação 30% desenvolvida do que se estivesse 100%.

Focar em definir bem os requisitos das entregas mais próximas é muito melhor que tentar documentar 100% do projeto antes mesmo de iniciar a codificação.

Sim estamos falando de metodologias ágeis como o Scrum por exemplo, um projeto de software é diferente de um projeto de construção civil e merece um framework de desenvolvimento interativo e incremental.

Planejamento

É necessário analisar qual será o porte da aplicação, não existe uma receita para todo tipo de aplicação, se ela for grande e complexa é necessário abordar alguma prática de arquitetura, por exemplo DDD.

Se a aplicação for simples é necessário evitar exageros e complexidades que não beneficiam as funcionalidades da aplicação.

Orientações como o KISS e o YAGNI dizem para evitar os exageros e manter a aplicação simples, é fato, mas isso não significa que você deve fazer tudo na camada de apresentação por exemplo, uma mínima divisão de responsabilidades é essencial para a qualidade de qualquer tipo de aplicação.

Arquitetura

Arquitetura é a base de tudo, é muito importante fazer a escolha ideal e evitar a famosa “arquitetura BOLOVO” de 3 camadas (Modelo, Business e DataAccess).
Hoje em dia está claro que apesar de funcionar e ser simples esse modelo traz muitos problemas.

É muito importante ter uma pessoa no papel de arquiteto, que conheça diversas estratégias de arquitetura e saiba aplicar bem os inúmeros patterns disponíveis.

Uma vez que possui sua arquitetura definida a aplicação deve se manter dentro do aspecto da arquitetura original, corromper camadas para acessar mais facilmente o banco ou para resolver mais rapidamente um problema pode ser considerado um crime.

Descaracterizar a arquitetura de uma aplicação é o primeiro passo para a famosa “Colcha de Retalhos”. O arquiteto ou líder técnico deve ser responsável por garantir que a arquitetura não esteja sendo corrompida e que seja mantida dentro de sua proposta em toda extensão da aplicação.

Codificação

Mesmo com uma arquitetura definida a tarefa de codificação ainda é complexa e não existem motivos para ser diferente. Codificar exige muitas habilidades além do próprio conhecimento da linguagem e plataforma.

É importantíssimo valorizar os princípios básicos da orientação à objetos como o SOLID que apesar de ser básico podemos dizer que grande parte dos desenvolvedores ainda não sabem como escrever código usando injeção de dependência (DIP) para evitar o alto acoplamento. Realizam heranças sem sentido apenas pelo fato de um objeto herdar hierarquicamente de outro no mundo real. Deixam o princípio de responsabilidade única de lado (SRP) e não criam classes extensíveis (OCP) deixando o código sempre aberto.

Entre outros pontos falhos não citados, os mencionados acima já são responsáveis por grande parte dos problemas existentes em nossas aplicações. Codificar não é uma tarefa menos grandiosa como arquitetar um sistema, pelo contrário, precisamos valorizar mais o programador que possui esses conhecimentos.

Padrões de codificação como nomenclaturas e regras são importantes para manter a expressividade e facilidade de leitura do código. Antigamente programadores se gabavam por fazer códigos que somente eles entendiam, isso não deve existir, o código é uma série de instruções que devem ser de leitura clara e leve, muitas vezes dispensando uma documentação própria.

Uma técnica de codificação que vem ganhando popularidade é o TDD, apesar do TDD ter seu nome diretamente relacionado com testes o TDD na verdade é sobre codificação, os testes que guiam a codificação via TDD servem para garantir a qualidade do código que no final também garantem a sua testabilidade.

Testes

Testes é um assunto complexo, primeiramente devemos entender que teste de software não é apenas rodar a aplicação e ver se tudo está funcionando.

Existe mais de um tipo de teste, podendo ser de unidade, de integração e etc.

Os testes de unidade são necessários quase sempre, podemos dizer que 80% de cobertura de código através dos testes é um resultado bem positivo. Testes de unidade são muito importantes para garantir a boa escrita do código e validar a sua funcionalidade durante o desenvolvimento. Se durante a codificação um teste falhar pode significar que alguma coisa foi feita de forma que o código deixou de funcionar como deveria, logo evitará o deploy prematuro em produção e que o cliente tenha a infelicidade de descobrir um novo bug.

Descobrir um bug em tempo de codificação é N vezes mais barato que descobrir um bug em produção, evita retrabalho, horas extras, replanejamento de deploy, insatisfação com o cliente etc.

Muitas pessoas alegam que escrever testes de unidade fazem o software custar mais caro, pois aumenta mais o esforço de codificação. Isto parece fazer sentido se olharmos apenas no sentido da entrega, mas mesmo assim não faz. Os testes exigem mais esforço de codificação, porém conforme a cobertura de testes aumenta a velocidade de entrega aumenta junto, pois os testes facilitam muito as futuras modificações.

Contabilizar o esforço apenas baseado na entrega é uma falha. Devemos sempre levar em conta a manutenção e evolução, e quando falhamos nesse aspecto estamos iniciando o ponto onde a aplicação vai se tornar cada vez mais complexa para se testar, evoluir, receber manutenções.

Costumo dizer que programamos uma aplicação durante 6 meses e a mantemos durante 3 anos ou mais, sendo assim nosso foco deveria ser na manutenção e evolução e não apenas na entrega. Todo lucro obtido numa entrega mal planejada será perdido durante a manutenção, podendo inclusive chegar ao negativo, e esse é um dos principais motivos que levam diversos projetos falharem e se transformarem em prejuízo quando deveriam continuar gerando lucros.

Os testes de unidade são de responsabilidade do desenvolvedor, os testes de integração e etc podem ser de responsabilidade de um profissional de qualidade ou simplesmente de toda a equipe (equipes multidisciplinares sabem codificar e testar).

Testes de unidade garantem a qualidade de escrita do código e de sua funcionalidade, um código que não está coberto por testes não é um código confiável. Não existe processo ágil de desenvolvimento sem testes, portanto está claro. Testar é preciso!

Quando tudo deu errado.

O planejamento da aplicação não foi bem feito, a arquitetura não foi bem desenhada para atender o propósito da aplicação, a codificação está estruturada, acoplada e sem padrão, não existem testes de unidade e realizar qualquer manutenção significa alterar diversas partes do código e ser obrigado a testar manualmente todas funcionalidades de ponta a ponta, mesmo assim sempre escapando alguns novos bugs.

As noites são longas quando é necessária alguma manutenção, o deploy em produção é uma aventura preocupante, a satisfação de trabalhar no projeto já não existe mais e a pressão não vale a pena.

O gestor do projeto não aceita mais tantos bugs e exige mais assertividade, questionando inclusive a capacidade técnica da equipe, o cliente não aceita mais os prazos para ajustes simples e não quer pagar a mais por isso também.

Não dá mais!  Vamos precisar reescrever essa aplicação do zero.


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações Web com arquitetura baseada em DDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade inscreva-se em meu curso:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos essa mensagem para o máximo de pessoas possíveis. 😉

SOLID – Teoria e Prática – Demo + Vídeo

SOLID – Teoria e Prática. É com certeza um dos temas mais debatidos no ramo de OOP, aprenda cada um dos princípios e como aplicá-los.

Este é um artigo complementar ao Orientação a Objeto – SOLID, neste primeiro artigo eu apresentei teoricamente o conceito do SOLID e seus benefícios.

SOLID – Teoria e Prática

Recapitulando

SOLID é um acrônimo dos cinco primeiros princípios da programação orientada a objetos e design de código identificados por Robert C. Martin (ou Uncle Bob) por volta do ano 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nesta palavra.

Os princípios SOLID deveriam ser aplicados por qualquer desenvolvedor, porém pouquíssimos profissionais preocupam-se em utilizá-los, para obtermos todos os reais benefícios da OOP é necessário atender aos 5 princípios do SOLID.

Lembrando também que além destes 5 princípios Uncle Bob também mapeou 3 outros princípios sobre Coesão e mais outros 3 sobre Acoplamento. Utilize este link para conhecê-los também.

SLIDES

VÍDEO (1h00)

* Assine meu canal no Youtube 🙂

SOURCE

Para visualizar o fonte e realizar o download do projeto clique aqui (GitHub)

Referências

Vamos continuar enriquecendo o assunto, poste aqui sua opinião ou dúvida.

SOLID – Open Closed Principle – OCP

Open Closed Principle, também conhecido como Princípio do Aberto Fechado.

OCP - Open Closed Principle

Este é o segundo princípio do SOLID e certamente o princípio mais polêmico, desconhecido e não utilizado.

Software entities (classes, modules, functions, etc.) should be open for 
extension, but closed for modification

Entidades de software (classes, módulos, funções, etc) devem estar abertas para extensão, mas fechadas para modificação.

Software é evolutivo, raramente um software é feito uma vez e nunca mais será modificado. Sendo assim onde esse princípio tenta chegar?

Extensibilidade

É uma das chaves da orientação a objetos, quando um novo comportamento ou funcionalidade precisar ser adicionado é esperado que as existentes sejam estendidas e e não alteradas, assim o código original permanece intacto e confiável enquanto as novas são implementadas através de extensibilidade. Criar código extensível é uma responsabilidade do desenvolvedor maduro, utilizar design duradouro para um software de boa qualidade e manutenibilidade.

Abstração

Quando aprendemos sobre orientação a objetos com certeza ouvimos sobre abstração, é ela que permite que este princípio funcione. Se um software possui abstrações bem definidas logo ele estará aberto para extensão.

Na prática

Vou usar um exemplo bem simples para podermos entender facilmente como funciona.
Observe esta classe:

public enum TipoDebito { ContaCorrente, Poupanca }

public class Debito
{
    public void Debitar(int valor, TipoDebito tipo)
    {
        if (tipo == TipoDebito.Poupanca)
        {
            // Debita Poupanca
        }
        if (tipo == TipoDebito.ContaCorrente)
        {
            // Debita ContaCorrente
        }
    }
}

É uma classe de débito em conta que valida o tipo da conta para aplicar a regra de negócio correta para conta corrente e para conta poupança. Agora vamos supor que surgiu um novo tipo de débito em conta (conta investimento), logo seria necessário modificar a classe.

Qual é o problema de um IF a mais?
Se modificarmos a classe colocando mais um IF de validação, além de ter que substituirmos esta classe na publicação da nova versão, corremos o risco de introduzir alguns bugs em uma classe que já estava funcionando.

Além de ter que testar todos os tipos de débito em conta, um bug introduzido nesta modificação não pararia apenas o débito em conta investimento mas poderia causar que todos os tipos de débitos parassem de funcionar.

Não queremos isso certo? Na verdade queremos ter o mínimo de trabalho possível e maior garantia de qualidade.

Como deveria ser?

Vamos para um exemplo de um código usando abstração para gerar extensibilidade:

public abstract class Debito
{
    public abstract void Debitar(int valor);
}

public class DebitoContaCorrente : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Corrente
    }
}

public class DebitoContaPoupanca : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Poupança
    }
}

public class DebitoContaInvestimento : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Investimento
    }
}

Veja que possuímos agora uma abstração bem definida, onde todas as extensões implementam suas próprias regras de negócio sem necessidade de modificar uma funcionalidade devido mudança ou inclusão de outra.

O tipo de débito em conta de investimento foi implementado sem modificar nada, usando apenas a extensão. Além de tudo o código está muito mais bonito, entendível e fácil para aplicar cobertura de testes de unidade. Vale mencionar que também está de acordo com o primeiro princípio do SOLID o SRP

Conclusão

Este princípio nos atenta para um melhor design, tornando o software mais extensível e facilitando sua evolução sem afetar a qualidade do que já está desenvolvido.

Para o uso do Open Closed Principle é muito comum utilizarmos o Strategy Pattern do GoF, prometo explicá-lo em outro momento, apenas para não tornar este exemplo muito complexo.

Referências

SOLID – Single Responsibility Principle – SRP

Single Responsibility Principle, também conhecido como Princípio da Responsabilidade Única.

SOLID - Single Responsibility Principle - SRP

Este é o primeiro princípio do SOLID, um dos mais fáceis de entender e de aplicar.

"A class should have one, and only one, reason to change"

“Uma classe deve ter um, e apenas um, motivo para ser modificada”

Se uma classe só deve ter um motivo para ser modificada, certamente ela só deve ter uma única responsabilidade, logo:

Cada responsabilidade deve ser uma classe, porque uma responsabilidade é um eixo de mudança.

Veja esta classe:

public class DebitoContaCorrente
{
    public void ValidarSaldo(int valor) { }

    public void DebitarConta(int valor) { }

    public void EmitirComprovante() { }
}

O que esta classe faz?

Esta classe valida saldo em conta e debita valor da conta e emite comprovante.

Esta classe possui três responsabilidades, ou seja, ela tem três razões para ser modificada, problemas a vista, vamos imaginar que por algum motivo a regra de negócio da emissão de comprovante mudou, logo para aplicar a nova regra seria necessário modificar a classe DebitoContaCorrente.

Se por um acaso na modificação da classe algum bug não identificado foi para a produção não apenas a emissão de comprovante, mas sim todas as funcionalidades da classe poderiam estar comprometidas. O sistema deixaria de fazer o débito devido um problema com o comprovante.

Esse é apenas um exemplo de como o acoplamento pode trazer problemas, testes de unidade seriam muito mais complexos de serem desenvolvidos (e menos eficazes).
Ao modificar esta classe vários testes de integração necessitariam ser executados para garantir que uma funcionalidade não comprometeu as demais.

Alguns benefícios do Single Responsibility Principle:

  • Complexidade do código reduzida, mais explícita e direta;
  • Facilitação da legibilidade;
  • Redução de acoplamento;
  • Código limpo e testável;
  • Facilidade de evolução.

Como deveria ser?

Veja como a classe poderia ficar após um refactoring de aplicação do Single Responsibility Principle:

public class DebitoContaCorrente
{
    public void DebitarConta(int valor) { }
}

public class SaldoContaCorrente
{
    public void ValidarSaldo(int valor) { }
}

public class ComprovanteContaCorrente
{
    public void EmitirComprovante() { }
}

Cada classe com sua responsabilidade.
No início isso pode parecer exagero, mas não é, isto é uma promoção da qualidade do código e uma ótima maneira de obter os benefícios citados acima.

Conclusão

O Single Responsibility Principle é um dos mais importantes princípios do SOLID, deve ser aplicado para obtermos classes mais coesas e de baixo acoplamento.

Este é o tipo de princípio que todo código orientado a objetos deveria possuir.
Portanto antes de construir aquela classe que cadastra o usuário e envia o e-mail, lembre-se deste princípio.

Referências

Orientação a Objeto – SOLID

SOLID é um acrônimo dos cinco primeiros princípios da programação orientada a objetos e design de código identificados por Robert C. Martin (ou Uncle Bob) por volta do ano 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nesta palavra.

São eles:

Letra Sigla Nome Definição
S  SRP Principio da Responsabilidade Única Uma classe deve ter um, e somente um, motivo para mudar.
O  OCP Princípio Aberto-Fechado Você deve ser capaz de estender um comportamento de uma classe, sem modificá-lo.
L  LSP Princípio da Substituição de Liskov As classes base devem ser substituíveis por suas classes derivadas.
I  ISP Princípio da Segregação da Interface Muitas interfaces específicas são melhores do que uma interface única.
D  DIP Princípio da inversão da dependência Dependa de uma abstração e não de uma implementação.

Os princípios SOLID devem ser aplicados para se obter os benefícios da orientação a objetos, tais como:

  • Seja fácil de se manter, adaptar e se ajustar às alterações de escopo;
  • Seja testável e de fácil entendimento;
  • Seja extensível para alterações com o menor esforço necessário;
  • Que forneça o máximo de reaproveitamento;
  • Que permaneça o máximo de tempo possível em utilização.

Utilizando os princípios SOLID é possível evitar problemas muito comuns:

  • Dificuldade na testabilidade / criação de testes de unidade;
  • Código macarrônico, sem estrutura ou padrão;
  • Dificuldades de isolar funcionalidades;
  • Duplicação de código, uma alteração precisa ser feita em N pontos;
  • Fragilidade, o código quebra facilmente em vários pontos após alguma mudança.

Os princípios SOLID deveriam ser aplicados por qualquer desenvolvedor maduro, porém pouquíssimos profissionais preocupam-se em utilizá-los, sugiro que crie um sistema simples e utilize estes princípios para treinar, será uma experiência gratificante.

Este é apenas o artigo introdutório sobre SOLID, nos próximos abordarei cada princípio em um artigo separadamente, explicando e demonstrando com código e exemplos a proposta de cada um, continue acompanhando 😉

Referências: