Boas Práticas de OO (Princípios)  Msc Luiz Barboza
Princípios de Projeto Orientado a Objetos Open/Closed Principle (OCP) Princípio do Aberto/Fechado Liskov Substitution Principle (LSP) Princípio da Substituição de Liskov SRP - Single Responsability Principle  Princípio da responsabilidade única Don’t Repeat Yourself (DRY)  Não se repita Dependency Inversion Principle (DIP) Princípio da Inversão de Dependência Interface Segregation Principle (ISP) Princípio da Segregação de Interfaces
Open/Closed Principle (OCP) Princípio do Aberto/Fechado Um módulo deveria ser aberto para extensão mas fechado para modificação. Objetivo: criar módulos que sejam estensíveis sem precisarem ser modificados Conseqüências   Mudanças não se propagam para código que já existe Se você não precisa mudar um código, então provavelmente você não vai quebrá-lo.
Liskov Substitution Principle (LSP) Princípio da Substituição de Liskov Sempre que uma classe cliente espera uma instância de uma classe base A, uma instância de uma subclasse B de A deve poder ser usada no lugar.(relação É-UM) Objetivo: evitar que premissas em relação a classes base não sejam quebradas por suas subclasses Exemplo clássico: elipse e círculo
SRP - Single Responsability Principle Princípio da responsabilidade única ALTA COESÃO   Deve existir um e somente UM MOTIVO para que uma classe mude Conseqüências Baseado no princípio da coesão funcional, uma classe deve ter uma única responsabilidade; Se uma classe possuir mais de uma responsabilidade, deve-se considerar sua decomposição em duas ou mais classes; Cada responsabilidade é um “eixo de mudança” e as fontes de mudança devem ser isoladas;
Don’t Repeat Yourself (DRY) Não se repita ALTA COESÃO   Cada informação e comportamento do seu sistema deve estar em um único lugar sensível.  Ou seja, não deve existir código repetido através do sistema.
Dependency Inversion Principle (DIP) Princípio da Inversão de Dependência BAIXO ACOPLAMENTO   Dependa sempre de interfaces abstratas, e nunca de classes concretas Justificativa: Implementações concretas são mais propensas a mudanças Possibilidade de alterar (ou incluir novas) implementações sem necessidade de alterar classes clientes
Interface Segregation Principle (ISP) Princípio da Segregação de Interfaces BAIXO ACOPLAMENTO   Expor o mínimo possível necessário para cada uso de uma determinada classe Uma interface pra cada possível tipo de cliente. Objetivos: Minimizar dependências Facilitar compreensão dos módulos clientes
Boas Práticas de OO (Princípios)  Msc Luiz Barboza

Mais conteúdo relacionado

PDF
Boas práticas para desenvolvimento de software
PPT
Dojo solid
PPTX
SOLID - Teoria e Prática
PPTX
Princípios SOLID
PPSX
Padrão de Projeto Observer
PPTX
Lucas e pedro1
PDF
Introdução ao vuex
PPTX
Princípios SOLID
Boas práticas para desenvolvimento de software
Dojo solid
SOLID - Teoria e Prática
Princípios SOLID
Padrão de Projeto Observer
Lucas e pedro1
Introdução ao vuex
Princípios SOLID

Semelhante a boas praticas (20)

PPTX
SOLID Os princípios da linguagem orientada a objeto
PPTX
Princípios solid
PPTX
QConSP 2012 - SOLID em 5 minutos
PDF
OCP - The Open Close Principle - Princípio aberto/fechado
PDF
Princípios de Programação Orientada a Objetos Solid, dry e kiss
PDF
Princípios S.O.L.I.D.
PPTX
Princípios SOLID
PDF
PPTX
PPTX
TDC 2019 Clean Architeture com .net core
PDF
Livro Código limpo: Classes
PDF
Fundamentos e princípios do projeto orientado a objetos
PDF
Cocoaheads Brasil SP - 26/04/16 - SOLID
PDF
Pragmatismo e Padroes - Um limiar tenue entre o sucesso e o fracasso do seu p...
PPTX
Estudos Technocorp
PDF
Common closure principle
PPTX
Clean architecture
ODP
Apresentacao Boas praticas, revisão java, SOLID, KISS, DRY, design patterns, ...
PPT
PPTX
TDC2022 - Como desacoplar Componentes aplicando DI e IoC com Kotlin e Spring....
SOLID Os princípios da linguagem orientada a objeto
Princípios solid
QConSP 2012 - SOLID em 5 minutos
OCP - The Open Close Principle - Princípio aberto/fechado
Princípios de Programação Orientada a Objetos Solid, dry e kiss
Princípios S.O.L.I.D.
Princípios SOLID
TDC 2019 Clean Architeture com .net core
Livro Código limpo: Classes
Fundamentos e princípios do projeto orientado a objetos
Cocoaheads Brasil SP - 26/04/16 - SOLID
Pragmatismo e Padroes - Um limiar tenue entre o sucesso e o fracasso do seu p...
Estudos Technocorp
Common closure principle
Clean architecture
Apresentacao Boas praticas, revisão java, SOLID, KISS, DRY, design patterns, ...
TDC2022 - Como desacoplar Componentes aplicando DI e IoC com Kotlin e Spring....
Anúncio

Mais de lcbj (20)

PPT
5 Ads
PPT
ISO Produto de Software
PPT
Padroes Projeto
PPT
Soa Bpm Eup
PPT
Uml
PPT
Mvc
PPT
4 Ads
PPT
_2_C
PPT
4 C
PPT
3 C
PPT
Sixsigma
PPT
3 ADSS
PPT
2 C
PPT
2 Ads
PPT
Itil
PPT
Pmbok
PPT
2 C
PPT
1 C
PPT
0 Intro
PPT
1 Ads
5 Ads
ISO Produto de Software
Padroes Projeto
Soa Bpm Eup
Uml
Mvc
4 Ads
_2_C
4 C
3 C
Sixsigma
3 ADSS
2 C
2 Ads
Itil
Pmbok
2 C
1 C
0 Intro
1 Ads
Anúncio

boas praticas

  • 1. Boas Práticas de OO (Princípios) Msc Luiz Barboza
  • 2. Princípios de Projeto Orientado a Objetos Open/Closed Principle (OCP) Princípio do Aberto/Fechado Liskov Substitution Principle (LSP) Princípio da Substituição de Liskov SRP - Single Responsability Principle Princípio da responsabilidade única Don’t Repeat Yourself (DRY) Não se repita Dependency Inversion Principle (DIP) Princípio da Inversão de Dependência Interface Segregation Principle (ISP) Princípio da Segregação de Interfaces
  • 3. Open/Closed Principle (OCP) Princípio do Aberto/Fechado Um módulo deveria ser aberto para extensão mas fechado para modificação. Objetivo: criar módulos que sejam estensíveis sem precisarem ser modificados Conseqüências Mudanças não se propagam para código que já existe Se você não precisa mudar um código, então provavelmente você não vai quebrá-lo.
  • 4. Liskov Substitution Principle (LSP) Princípio da Substituição de Liskov Sempre que uma classe cliente espera uma instância de uma classe base A, uma instância de uma subclasse B de A deve poder ser usada no lugar.(relação É-UM) Objetivo: evitar que premissas em relação a classes base não sejam quebradas por suas subclasses Exemplo clássico: elipse e círculo
  • 5. SRP - Single Responsability Principle Princípio da responsabilidade única ALTA COESÃO Deve existir um e somente UM MOTIVO para que uma classe mude Conseqüências Baseado no princípio da coesão funcional, uma classe deve ter uma única responsabilidade; Se uma classe possuir mais de uma responsabilidade, deve-se considerar sua decomposição em duas ou mais classes; Cada responsabilidade é um “eixo de mudança” e as fontes de mudança devem ser isoladas;
  • 6. Don’t Repeat Yourself (DRY) Não se repita ALTA COESÃO Cada informação e comportamento do seu sistema deve estar em um único lugar sensível. Ou seja, não deve existir código repetido através do sistema.
  • 7. Dependency Inversion Principle (DIP) Princípio da Inversão de Dependência BAIXO ACOPLAMENTO Dependa sempre de interfaces abstratas, e nunca de classes concretas Justificativa: Implementações concretas são mais propensas a mudanças Possibilidade de alterar (ou incluir novas) implementações sem necessidade de alterar classes clientes
  • 8. Interface Segregation Principle (ISP) Princípio da Segregação de Interfaces BAIXO ACOPLAMENTO Expor o mínimo possível necessário para cada uso de uma determinada classe Uma interface pra cada possível tipo de cliente. Objetivos: Minimizar dependências Facilitar compreensão dos módulos clientes
  • 9. Boas Práticas de OO (Princípios) Msc Luiz Barboza