@augustohp@augustohp
@Ivonascimento@Ivonascimento
@lcobucci@lcobucci
@nelson_senna@nelson_senna
@netojoaobatista@netojoaobatista
@guilhermeblanco@guilhermeblanco
S.O.L.I.D.S.O.L.I.D.a 6 mãosa 6 mãos
Sólido, mas não engessadoSólido, mas não engessado
Código engessado apodrece
e cheira mal.
Sólido, mas não engessadoSólido, mas não engessado
Como evitar o apodrecimento
do código?
Sólido, mas não engessadoSólido, mas não engessado
Código S.O.L.I.D.

facilita a manutenção

mudanças não quebram o código

é reutilizável e reaproveitável
Sólido, mas não engessadoSólido, mas não engessado
E como meu código pode
ser S.O.L.I.D.?
S.R.P. - Princípio da responsabilidade únicaS.R.P. - Princípio da responsabilidade única
O primeiro passo,
é compreender responsabilidade.
S.R.P. - Princípio da responsabilidade únicaS.R.P. - Princípio da responsabilidade única
Responsabilidade única, por quê?
S.R.P. - Princípio da responsabilidade únicaS.R.P. - Princípio da responsabilidade única
Okay, tenho apenas uma
responsabilidade.
E agora?
S.R.P. - Princípio da responsabilidade únicaS.R.P. - Princípio da responsabilidade única
Seu código ainda fede;
Muito!
O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado
Agora você é proibido de
editar seu código.
O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado
Aberto e fechado?!
Não é antagônico?
O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado
Aberto para extensão;
Fechado para edição.
O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado
A implementação é irrelevante.
Trabalhe com abstrações.
O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado
Herança pode ser uma solução
para variar o comportamento.
O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado
Herança?!
Eu sei trabalhar com herança!
O.C.P. - Princípio Aberto/FechadoO.C.P. - Princípio Aberto/Fechado
class User extends Database {}
L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov
Herança é mais complexo do
que você imagina!
L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov
Se q(x) é uma propriedade
demonstrável dos objetos x de
tipo T. Então q(y) deve ser
verdadeiro para objetos y de tipo
S onde S é um subtipo de T.
L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov
WTF?!
L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov
Se q(x) é uma propriedade
demonstrável dos objetos x de
tipo T. Então q(y) deve ser
verdadeiro para objetos y de tipo
S onde S é um subtipo de T.
L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov
E como uso isso?
L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov
Validação de input nunca deve
ser mais forte na derivação, do
que é na classe base.
L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov
Validação do output nunca deve
ser mais fraco na derivação, do
que é na classe base.
L.S.P. - Princípio da substituição de LiskovL.S.P. - Princípio da substituição de Liskov
Se não posso editar o código,
como utilizo uma classe
derivada?
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
Trabalhando com abstrações e
invertendo as dependências.
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
Mas o que é dependência?
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
Em vez de criar as instâncias
dentro das classes, devemos
passá-las como parâmetros na
forma de abstrações.
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
Abstração é um conceito.
Uma ideia.
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
Confie na interface das coisas
e não espere conhecer os
detalhes da implementação.
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
Então é só eu criar uma interface
com todos os métodos
possíveis?
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
Esqueceu das
responsabilidades?
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
É esperado que seus objetos se
comportem de todas as formas
possíveis?
D.I.P. - Princípio da inversão das dependênciasD.I.P. - Princípio da inversão das dependências
Então qual a responsabilidade do
seu objeto?
I.S.P. - Princípio da segregação das interfacesI.S.P. - Princípio da segregação das interfaces
Faça com que sua interface deixe
os outros saberem dessa, e
somente dessa,
responsabilidade.
I.S.P. - Princípio da segregação das interfacesI.S.P. - Princípio da segregação das interfaces
Quanto mais coesa for a
interface, mais fácil será sua
reutilização.
Problemas de um mau designProblemas de um mau design
Rigidez
Uma única mudança, implica na
mudança de vários outros
componentes.
Problemas de um mau designProblemas de um mau design
Fragilidade
Quando mudamos alguma coisa,
partes inesperadas da aplicação
quebram.
Problemas de um mau designProblemas de um mau design
Imobilidade
Fica difícil reutilizar o código,
pois fica difícil extrair uma parte
de um todo.
Problemas de um mau designProblemas de um mau design
Há mais maus cheiros entre seus
objetos, do que essa vã
apresentação pode lhe mostrar.
@augustohp@augustohp
@Ivonascimento@Ivonascimento
@lcobucci@lcobucci
@nelson_senna@nelson_senna
@netojoaobatista@netojoaobatista
@guilhermeblanco@guilhermeblanco
Obrigado!Obrigado!

SOLID a 6 mãos

  • 1.
  • 2.
    Sólido, mas nãoengessadoSólido, mas não engessado Código engessado apodrece e cheira mal.
  • 3.
    Sólido, mas nãoengessadoSólido, mas não engessado Como evitar o apodrecimento do código?
  • 4.
    Sólido, mas nãoengessadoSólido, mas não engessado Código S.O.L.I.D.  facilita a manutenção  mudanças não quebram o código  é reutilizável e reaproveitável
  • 5.
    Sólido, mas nãoengessadoSólido, mas não engessado E como meu código pode ser S.O.L.I.D.?
  • 6.
    S.R.P. - Princípioda responsabilidade únicaS.R.P. - Princípio da responsabilidade única O primeiro passo, é compreender responsabilidade.
  • 7.
    S.R.P. - Princípioda responsabilidade únicaS.R.P. - Princípio da responsabilidade única Responsabilidade única, por quê?
  • 8.
    S.R.P. - Princípioda responsabilidade únicaS.R.P. - Princípio da responsabilidade única Okay, tenho apenas uma responsabilidade. E agora?
  • 9.
    S.R.P. - Princípioda responsabilidade únicaS.R.P. - Princípio da responsabilidade única Seu código ainda fede; Muito!
  • 10.
    O.C.P. - PrincípioAberto/FechadoO.C.P. - Princípio Aberto/Fechado Agora você é proibido de editar seu código.
  • 11.
    O.C.P. - PrincípioAberto/FechadoO.C.P. - Princípio Aberto/Fechado Aberto e fechado?! Não é antagônico?
  • 12.
    O.C.P. - PrincípioAberto/FechadoO.C.P. - Princípio Aberto/Fechado Aberto para extensão; Fechado para edição.
  • 13.
    O.C.P. - PrincípioAberto/FechadoO.C.P. - Princípio Aberto/Fechado A implementação é irrelevante. Trabalhe com abstrações.
  • 14.
    O.C.P. - PrincípioAberto/FechadoO.C.P. - Princípio Aberto/Fechado Herança pode ser uma solução para variar o comportamento.
  • 15.
    O.C.P. - PrincípioAberto/FechadoO.C.P. - Princípio Aberto/Fechado Herança?! Eu sei trabalhar com herança!
  • 16.
    O.C.P. - PrincípioAberto/FechadoO.C.P. - Princípio Aberto/Fechado class User extends Database {}
  • 17.
    L.S.P. - Princípioda substituição de LiskovL.S.P. - Princípio da substituição de Liskov Herança é mais complexo do que você imagina!
  • 18.
    L.S.P. - Princípioda substituição de LiskovL.S.P. - Princípio da substituição de Liskov Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.
  • 19.
    L.S.P. - Princípioda substituição de LiskovL.S.P. - Princípio da substituição de Liskov WTF?!
  • 20.
    L.S.P. - Princípioda substituição de LiskovL.S.P. - Princípio da substituição de Liskov Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.
  • 21.
    L.S.P. - Princípioda substituição de LiskovL.S.P. - Princípio da substituição de Liskov E como uso isso?
  • 22.
    L.S.P. - Princípioda substituição de LiskovL.S.P. - Princípio da substituição de Liskov Validação de input nunca deve ser mais forte na derivação, do que é na classe base.
  • 23.
    L.S.P. - Princípioda substituição de LiskovL.S.P. - Princípio da substituição de Liskov Validação do output nunca deve ser mais fraco na derivação, do que é na classe base.
  • 24.
    L.S.P. - Princípioda substituição de LiskovL.S.P. - Princípio da substituição de Liskov Se não posso editar o código, como utilizo uma classe derivada?
  • 25.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências Trabalhando com abstrações e invertendo as dependências.
  • 26.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências Mas o que é dependência?
  • 27.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências Em vez de criar as instâncias dentro das classes, devemos passá-las como parâmetros na forma de abstrações.
  • 28.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências Abstração é um conceito. Uma ideia.
  • 29.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências Confie na interface das coisas e não espere conhecer os detalhes da implementação.
  • 30.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências Então é só eu criar uma interface com todos os métodos possíveis?
  • 31.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências Esqueceu das responsabilidades?
  • 32.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências É esperado que seus objetos se comportem de todas as formas possíveis?
  • 33.
    D.I.P. - Princípioda inversão das dependênciasD.I.P. - Princípio da inversão das dependências Então qual a responsabilidade do seu objeto?
  • 34.
    I.S.P. - Princípioda segregação das interfacesI.S.P. - Princípio da segregação das interfaces Faça com que sua interface deixe os outros saberem dessa, e somente dessa, responsabilidade.
  • 35.
    I.S.P. - Princípioda segregação das interfacesI.S.P. - Princípio da segregação das interfaces Quanto mais coesa for a interface, mais fácil será sua reutilização.
  • 36.
    Problemas de ummau designProblemas de um mau design Rigidez Uma única mudança, implica na mudança de vários outros componentes.
  • 37.
    Problemas de ummau designProblemas de um mau design Fragilidade Quando mudamos alguma coisa, partes inesperadas da aplicação quebram.
  • 38.
    Problemas de ummau designProblemas de um mau design Imobilidade Fica difícil reutilizar o código, pois fica difícil extrair uma parte de um todo.
  • 39.
    Problemas de ummau designProblemas de um mau design Há mais maus cheiros entre seus objetos, do que essa vã apresentação pode lhe mostrar.
  • 40.