Fundamentos e princípios do projeto orientado a objetos

  • 6,210 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
6,210
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
116
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Fundamentos e Princípios do Projeto Orientado a Objetos Autor: Evandro João Agnes evandroagnes@yahoo.com.br
  • 2. Abstração Seleção de alguns aspectos relevantes a uma determinada análise, suprimindo outros Serviços e atributos aplicáveis a objetos dentro de um determinado contexto2
  • 3. Classes e Objetos Classe Descrição de um conjunto de objetos similares Abstratas ou Concretas Objeto Reúnem na mesma estrutura: Atributos (dados) que definem o estado Operações que definem o comportamento e manipulam os dados Identidade de objetos Retenção de estado3
  • 4. Encapsulamento Esconder detalhes de implementação do estado e comportamento do objeto Objetos são acessados apenas pela interface externa definida para eles Detalhes de implementação das classes podem ser alterados sem que as aplicações necessitem de alterações4
  • 5. Mensagem Comunicação feita entre objetos Chamadas a métodos5
  • 6. Herança Permite que novas classes sejam construídas usando código e características declaradas em outras classes Relação do tipo “é um” entre classes Super-classes e sub-classes Sub-classe herda todos atributos e métodos da super-classe6
  • 7. Polimorfismo Propriedade na qual uma chamada genérica de um método pode ser executada de diferentes maneiras de acordo com o objeto que fez a chamada Exemplo Classe Reta: método desenhar() Classe Círculo: método desenhar()7
  • 8. Relacionamentos Associação Relação do tipo “tem um” entre objetos Agregação Relação do tipo “todo-parte” Dependência fraca Composição Relação do tipo “todo-parte” Dependência forte8
  • 9. Interdependência Elementos que compartilham alguma necessidade Tipos de Interdependência Nome Tipo ou classe Convenção Algoritmo Posição Valor Identidade9
  • 10. Interdependência Princípios Minimizar a interdependência total através do encapsulamento Minimizar qualquer interdependência que cruze as fronteiras do encapsulamento Maximizar a interdependência dentro das fronteiras do encapsulamento Abusos Função amigável Herança sem restrição Detalhes internos do algoritmo de uma classe relevantes para outras classes10
  • 11. Domínios Domínio de Apresentação Baixa reutilização Domínio de Aplicação Média Domínio de Negócio reutilização Domínio de Arquitetura Alta Domínio de Base reutilização11
  • 12. Grau de dependência ou acoplamento Conjunto de classes que uma classe se baseia para operar Grau de dependência pode ser Direto Indireto Classes em domínios altos tem alto grau de dependência indireto e classes em domínios baixos tem baixo grau de dependência indireto12
  • 13. Grau de dependência ou acoplamento Acoplamento é o caminho para o Lado Negro da Força! Conduz para complexidade Conduz para confusão Conduz ao sofrimento Uma vez que você inicie o caminho para o Lado Negro, ele sempre irá dominar seu destino. “Consumir você ele irá!” Desacoplar através de abstrações e interfaces!13
  • 14. Lei de Demeter Cada unidade deve conhecer apenas unidades intimamente relacionadas a ela Segundo a Lei de Demeter as mensagens devem ser enviadas apenas para: si mesmo - métodos do objeto seus objetos - atributos da instância parâmetros recebidos pelo método objetos criados pelo método14
  • 15. Coesão Classes com alta coesão Todas as características contribuem para a abstração de tipo implementada pela classe Classes com baixa coesão Apresenta um conjunto de características diferentes15
  • 16. Problemas de coesão Coesão de instância mista Ter algumas características que são definidas apenas para alguns objetos da classe Coesão de domínio misto Uma classe contém um elemento que cria dependência com uma classe de domínio diferente que não tem qualquer tipo de negócio com a classe* Coesão de papel misto Uma classe contém um elemento que diretamente cria dependência de uma classe de mesmo domínio que não tem qualquer tipo de negócio com a classe* * Uma classe B não tem qualquer tipo de negócio com A se A puder ser plenamente definida sem qualquer noção de B16
  • 17. Problema: Coesão de instância mista17
  • 18. Problema: Coesão de domínio misto18
  • 19. Problema: Coesão de papel misto19
  • 20. Espaço-estado e comportamento Espaço-estado de uma classe é a totalidade de estados permitidos para qualquer objeto da classe Cada componente do estado (atributos) de um objeto define uma dimensão É o conjunto de valores de dimensões válidas para um objeto O modo como o objeto muda de estado é o seu comportamento O comportamento permitido de uma classe é o conjunto de transições que o objeto pode fazer entre os estados do espaço-estado20
  • 21. Espaço-estado e comportamento O espaço-estado de uma subclasse deve estar contido inteiramente dentro do espaço-estado da superclasse O espaço-estado de uma subclasse pode ter mais dimensões que a superclasse21
  • 22. Invariante de classe Condição que todo objeto da classe deve satisfazer em todo o seu ciclo de vida São restrições no espaço-estado do objeto A invariante nunca deve ser quebrada22
  • 23. Pré-condições e pós-condições Devem garantir a invariante do objeto Toda operação tem uma pré-condição e uma pós- condição A pré-condição é uma condição que deve ser verdadeira quando a operação começar a executar A pós-condição é uma condição que deve ser verdadeira quando a operação finalizar sua execução23
  • 24. Conformidade de tipo Um sub-tipo deve se conformar a seu super-tipo O sub-tipo pode ser utilizado em qualquer contexto em que o super-tipo seja esperado A invariante da subclasse deve ser pelo menos tão forte quanto a invariante da super-classe A pré-condição de qualquer operação deve ser igual ou menos restritiva que a operação correspondente da super-classe A pós-condição de qualquer operação deve ser igual ou mais restritiva que a operação correspondente na super-classe24
  • 25. Comportamento fechado O comportamento herdado deve respeitar a invariante da sub-classe Nem sempre é possível, neste caso deve-se efetuar alguma ação corretiva evitar herança dos métodos que não respeitem a invariante suprimir os métodos de modo que ele não tenha efeito (possivelmente lançando uma exceção) estar preparado para reclassificar o objeto25
  • 26. Projeto de Qualidade Fácil de entender Fácil de alterar Fácil de reusar26
  • 27. Projeto Ruim Rígido Difícil de alterar Uma alteração requer uma cascata de outras alterações Impacto das alterações não consegue ser previsto Frágil A cada alteração novos erros aparecem em áreas aparentemente desconectadas Imobilizado Sem muita possibilidade de reuso Partes desejadas de um componente possui muitas partes indesejadas para o reuso27
  • 28. Projeto Ruim Pegajoso Alterações corretas são mais difíceis de fazer que as erradas (bacalhau!) Obscuro Difícil de entender Complexidade desnecessária Repetição desnecessária28
  • 29. Princípios de Projeto Princípio da Responsabilidade Única The Single Responsibility Principle (SRP) Princípio do Aberto-Fechado The Open-Closed Principle (OCP) Princípio de Substituição de Liskov The Liskov Substitution Principle (LSP)29
  • 30. Princípios de Projeto Princípio da Inversão de Dependência Dependency Inversion Principle (DIP) Princípio de Reuso de Composição The Composite Reuse Principle (CRP) Princípio de Segregação de Interface The Interface Segregation Principle (ISP)30
  • 31. The Single Responsibility Principle Uma classe deveria ter apenas uma razão para mudar Responsabilidade = razão para mudança Múltiplas responsabilidades = acoplamento alto, baixa coesão Responsabilidades são eixos de alteração Se uma classe faz mais de uma coisa, separe em classes diferentes31
  • 32. The Single Responsibility Principle Podemos melhorar este projeto!32
  • 33. The Single Responsibility Principle33
  • 34. The Single Responsibility Principle public class Grupo { private List servidores; public List getServidores() { return servidores; } public void setServidores(List servidores) { this.servidores = servidores; } } public class Servidor { private String login; private Grupo meuGrupo; public Servidor (String login, Grupo grupo) { this.login = login; this.meuGrupo = grupo; meuGrupo.getServidores().add(this.login); } }34
  • 35. The Single Responsibility Principle public class Grupo { private HashMap servidores; public HashMap getServidores() { return servidores; } public void setServidores(HashMap servidores) { this.servidores = servidores; } } public class Servidor { private String login; private Grupo meuGrupo; public Servidor (String login, Grupo grupo) { this.login = login; this.meuGrupo = grupo; meuGrupo.getServidores().put("login", this.login); } }35
  • 36. The Single Responsibility Principle public class Grupo { private HashMap servidores; public void IncluirServidor(Servidor servidor){ // Regra para inserir Servidor... } } public class Servidor { private String login; private Grupo meuGrupo; public Servidor (String login, Grupo grupo) { this.login = login; this.meuGrupo = grupo; meuGrupo.IncluirServidor(this); } }36
  • 37. The Open-Closed Principle Classes devem estar abertas para extensão e fechadas para modificação Quando os requisitos mudam (e eles mudam!) o projeto deve permitir estender o comportamento adicionando novo código e não alterando o comportamento do código existente Se a alteração de uma classe ou método resultar em uma cascata de alterações em outras classes e métodos, você tem um projeto “ruim”37
  • 38. The Open-Closed Principle Separe o que varia Encapsular o que varia para que não afete o resto do código Menos conseqüências indesejadas Mais flexibilidade Abstração e polimorfismo são a chave para este princípio38
  • 39. The Open-Closed Principle public class Matricula { private BigDecimal totalCred; private String tipoMatr; private Obrigacao obrigacao; public void matricular(){ // ... obrigacao.calcular(totalCred, tipoMatr); } } public class Obrigacao { public BigDecimal calcular(BigDecimal creditos, String tipo){ BigDecimal valor = null; if (tipo.equals("curricular")) { // Calcula matricula curricular } else if (tipo.equals("extra-curricular")){ // Calcula valor extra-curricular } else { // Calcula valor padrao } return valor; } }39
  • 40. The Open-Closed Principle40
  • 41. The Liskov Substitution Principle Conformidade de Tipo Sub-tipos podem substituir super-tipos Guia para criação de abstrações Contratos Violando este princípio podemos violar também o Princípio do Aberto-Fechado41
  • 42. The Liskov Substitution Principle42
  • 43. The Liskov Substitution Principle public class Bolsa { /** * Pre-condicao: valor não pode ultrapassar o devido * @param valor Valor do desconto lancado */ public void lancarDesconto(BigDecimal valor){ } } public class Financiamento extends Bolsa { /** * Pre-condicao: deve ser menor que o devido * @param valor Valor do desconto lancado */ public void lancarFinanciamento(BigDecimal valor){ } }43
  • 44. The Liskov Substitution Principle44
  • 45. Dependency Inversion Principle Dependa de abstrações (ou interfaces) e não de classes concretas Programe para uma interface, não para uma implementação Explora o polimorfismo Interface pode ser um super-tipo Alterações em classes que implementam uma interface não quebram código cliente45
  • 46. Dependency Inversion Principle46
  • 47. The Composite Reuse Principle Preferir a composição em relação a herança Herança excessiva pode causar fragilidade e hierarquias complexas de classes Herança pode quebrar o encapsulamento Com herança podemos sobrescrever um método, às vezes indesejável. Na composição os métodos devem ser utilizados como foram definidos Novas funcionalidades podem ser agregadas sem alteração no código existente (Princípio do Aberto- Fechado)47
  • 48. The Composite Reuse Principle Herança Comportamento é herdado Não podemos alterar o comportamento sem escrever mais código Composição Comportamento como um atributo Mais flexibilidade Permite alterar o comportamento em tempo de execução48
  • 49. The Composite Reuse Principle49
  • 50. The Composite Reuse Principle50
  • 51. The Composite Reuse Principle51
  • 52. The Composite Reuse Principle Cálculo do bônus passou a ser diferente para os empregados em tempo integral O que fazer para garantir um bom reuso sem código duplicado?52
  • 53. The Composite Reuse Principle53
  • 54. The Interface Segregation Principle Interfaces para específicos tipos de cliente são melhores que uma interface de propósito geral Clientes não deveriam ser forçados a depender de interfaces que eles não utilizam Interfaces muito grandes podem introduzir acoplamentos não desejados entre os clientes ISP não recomenda que seja criada uma interface para cada classe cliente, mas que as classes sejam classificadas por tipo Caso 2 ou mais tipos de clientes utilizem o mesmo método, este deve estar em ambas interfaces54
  • 55. The Interface Segregation Principle55
  • 56. The Interface Segregation Principle56
  • 57. Referências Fundamentals of Object-Oriented Design in UML - Meilir Page-Jones Head First Design Patterns - Elisabeth Freeman, Eric Freeman, Bert Bates and Kathy Sierra Design Principles e Design Patterns http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Domain Driven Design Quickly http://www.infoq.com/minibooks/domain-driven-design-quickly Contratos Nulos http://fragmental.com.br/wiki/index.php/Contratos_Nulos57
  • 58. Referências Lei de Demeter http://c2.com/cgi/wiki?LawOfDemeter Articles for Object Oriented Design http://www.objectmentor.com/resources/publishedArticles.html58