All posts tagged SOLID

Salve, salve, galera, vamos encerrar nosso bate-papo sobre os princípios SOLID com o último princípio, o da inversão de dependências. Esse princípio diz que:

- Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
– Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

De forma geral, não devemos depender de implementações  e sim de abstrações.

Mas e ae ??? Onde fica o exemplo ???

Read more


Salve, salve, galera, vamos continuar nossa conversa sobre os princípios SOLID. Agora vamos falar do princípio da segregação de interface. Esse princípio nos diz que;

Os clientes não devem ser forçados a depender de interfaces que eles não usam.

Quer dizer, não podemos ter uma classe dependendo de uma interface que não faz sentido para ela, ou que o obrigue a implementar métodos que não fazem sentido. Em outras palavras, damos preferencia para interfaces especificas ao invés de interfaces genéricas.

Em linhas gerais, imaginem que tenhamos uma Classe PessoaFisica e uma PessoaJuridica ambas implementando uma interface IPessoa, acontece que colocamos nessa interface um método ObterPeloCNPJ(…) que sentido faz esse método para a classe PessoaFisica ? Devemos criar interfaces menos genéricas e usa-las então. Poderíamos como uma solução para esse problemas, ter ainda uma interface IPessoa, porem deveríamos ainda ter uma interface IPessoaFisica e uma IPessoaJuridica e deixar os pontos específicos dentro de cada uma.

Esse principio se trata de uma dos mais simples de entendimento e de aplicar. E gera um grande controle quando estamos falando de equipes de médio/grande porte.

Pessoal nesse princípio não vou fazer um exemplo, mas caso surja alguma duvida não exitem em entrar em contato.


Salve, salve galera, continuando nossa conversa sobre os princípios SOLID vamos falar agora sobre o princípio aberto/fechado. Esse certamente se trata de um dos menos conhecidos.

Esse princípio diz que:

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

E ae ? o que isso quer dizer ?

Quer dizer que nossas classes devem estar aptas para serem extendidas mas fechadas para mudanças.

Uma das práticas do dia-a-dia mais utilizadas se trata de podermos extender uma classe para adicionarmos funcionalidades nela sem que as funcionalidades já implementadas sejam impactadas.

Falou, falou, falou e não entendi nada ! Cade o exemplo ???

Read more


Salve, salve galera, conforme tínhamos conversado aqui, vamos começar a falar sobre os princípios SOLID.

O primeiro principio a falarmos sera o principio da responsabilidade unica.

Esse principio se trata o de mais fácil entendimento, o de mais fácil aplicação e um dos que menos vemos no dia-a-dia. O SRP define que :

Uma classe deve ter um e apenas um motivo para ser modificada.

Mas podemos ser mais claros ainda, dizendo que cada classe pode representar apenas uma responsabilidade, ou em termos mais comuns do dia-a-dia , fazer apenas uma coisa, para que assim, possamos muda-la apenas se essa função tiver que ser modificada.

Read more


Salve, salve galera, hoje vamos falar sobre alguns principios de orientacao a objetos que sao muito uteis no dia-a-dia e que muitos desenvolvedores desconhecem. Se trata dos principios SOLID.

O termo SOLID se trata de uma abreviacao ( ou de um acronimo como preferir) das primeiras letras de 5 principios muito utilizados e que garantem uma maior estabilidade do codigo.

Os princípios são os seguintes:

  • Single responsibility principle (SRP) – Principio da responsabilidade unica ( Veja AQUI )
  • Open/closed principle – Principio aberto/fechado
  • Liskov substitution principle – Principio da substituição de liskov
  • Interface segregation principle – Principio da segregação de interface
  • Dependency inversion principle – Principio da inversão de dependência

Não vou entrar em detalhes deles por que iremos criar um artigo para detalhar cada um.

Ma de maneira geral temos em comum para todos:

  • Alta taxa de manutenção
  • Facilidade de testes
  • Maior aproveitamento
  • Fácil de estender
  • Garantir integridade da aplicação
  • Evitar códigos defeituoso
  • Evitar código duplicados
  • Etc.

Esses princípios parecem óbvios porem poucos desenvolvedores e ate mesmos arquitetos utilizam.

Eles garantem que temos uma padronizam e uma melhor utilização das ferramentas (independente da tecnologia) e que consigamos extrair o máximo delas.

Nos próximos artigos iremos abordar de maneira bem pratica cada um.

Ate a próxima galera.