fundamentos e princípios do projeto orientado a objetos

58
Fundamentos e Princípios do Projeto Orientado a Objetos Autor: Evandro João Agnes [email protected]

Upload: evandro-agnes

Post on 11-Jun-2015

6.975 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Fundamentos e princípios do projeto orientado a objetos

Fundamentos e Princípios do ProjetoOrientado a Objetos

Autor: Evandro João [email protected]

Page 2: Fundamentos e princípios do projeto orientado a objetos

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 contexto

Page 3: Fundamentos e princípios do projeto orientado a objetos

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 estado

Page 4: Fundamentos e princípios do projeto orientado a objetos

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ções

Page 5: Fundamentos e princípios do projeto orientado a objetos

5

Mensagem

Comunicação feita entre objetos

Chamadas a métodos

Page 6: Fundamentos e princípios do projeto orientado a objetos

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-classe

Page 7: Fundamentos e princípios do projeto orientado a objetos

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()

Page 8: Fundamentos e princípios do projeto orientado a objetos

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 forte

Page 9: Fundamentos e princípios do projeto orientado a objetos

9

Interdependência

Elementos que compartilham alguma necessidade

Tipos de Interdependência

Nome

Tipo ou classe

Convenção

Algoritmo

Posição

Valor

Identidade

Page 10: Fundamentos e princípios do projeto orientado a objetos

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 classes

Page 11: Fundamentos e princípios do projeto orientado a objetos

11

Domínios

Domínio de Aplicação

Domínio de Negócio

Domínio de Arquitetura

Domínio de Base

Baixareutilização

Médiareutilização

Altareutilização

Domínio de Apresentação

Page 12: Fundamentos e princípios do projeto orientado a objetos

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 indireto

Page 13: Fundamentos e princípios do projeto orientado a objetos

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!

Page 14: Fundamentos e princípios do projeto orientado a objetos

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étodo

Page 15: Fundamentos e princípios do projeto orientado a objetos

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 diferentes

Page 16: Fundamentos e princípios do projeto orientado a objetos

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 B

Page 17: Fundamentos e princípios do projeto orientado a objetos

17

Problema: Coesão de instância mista

Page 18: Fundamentos e princípios do projeto orientado a objetos

18

Problema: Coesão de domínio misto

Page 19: Fundamentos e princípios do projeto orientado a objetos

19

Problema: Coesão de papel misto

Page 20: Fundamentos e princípios do projeto orientado a objetos

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-estado

Page 21: Fundamentos e princípios do projeto orientado a objetos

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 superclasse

Page 22: Fundamentos e princípios do projeto orientado a objetos

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 quebrada

Page 23: Fundamentos e princípios do projeto orientado a objetos

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ção

Page 24: Fundamentos e princípios do projeto orientado a objetos

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-classe

Page 25: Fundamentos e princípios do projeto orientado a objetos

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 objeto

Page 26: Fundamentos e princípios do projeto orientado a objetos

26

Projeto de Qualidade

Fácil de entender

Fácil de alterar

Fácil de reusar

Page 27: Fundamentos e princípios do projeto orientado a objetos

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 reuso

Page 28: Fundamentos e princípios do projeto orientado a objetos

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ária

Page 29: Fundamentos e princípios do projeto orientado a objetos

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)

Page 30: Fundamentos e princípios do projeto orientado a objetos

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)

Page 31: Fundamentos e princípios do projeto orientado a objetos

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 diferentes

Page 32: Fundamentos e princípios do projeto orientado a objetos

32

The Single Responsibility Principle

Podemos melhorar este projeto!!!

Page 33: Fundamentos e princípios do projeto orientado a objetos

33

The Single Responsibility Principle

Page 34: Fundamentos e princípios do projeto orientado a objetos

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);

}}

Exemplo de código...

Page 35: Fundamentos e princípios do projeto orientado a objetos

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);

}}

E se alterarmos a lista de servidores para um HashMap?

A classe Servidor precisa ser alterada também...

Page 36: Fundamentos e princípios do projeto orientado a objetos

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);

}}

Se a regra para incluir servidor for responsabilidade do Grupo, o código da classe Servidor não precisa ser alterado...

Page 37: Fundamentos e princípios do projeto orientado a objetos

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”

Page 38: Fundamentos e princípios do projeto orientado a objetos

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ípio

Page 39: Fundamentos e princípios do projeto orientado a objetos

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;

}}

Page 40: Fundamentos e princípios do projeto orientado a objetos

40

The Open-Closed Principle

Page 41: Fundamentos e princípios do projeto orientado a objetos

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-Fechado

Page 42: Fundamentos e princípios do projeto orientado a objetos

42

The Liskov Substitution Principle

Page 43: Fundamentos e princípios do projeto orientado a objetos

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 lancarDesconto(BigDecimal valor){

}}

Page 44: Fundamentos e princípios do projeto orientado a objetos

44

The Liskov Substitution Principle

Page 45: Fundamentos e princípios do projeto orientado a objetos

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 cliente

Page 46: Fundamentos e princípios do projeto orientado a objetos

46

Dependency Inversion Principle

Page 47: Fundamentos e princípios do projeto orientado a objetos

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)

Page 48: Fundamentos e princípios do projeto orientado a objetos

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ção

Page 49: Fundamentos e princípios do projeto orientado a objetos

49

The Composite Reuse Principle

Exemplo de uso de herança:

Page 50: Fundamentos e princípios do projeto orientado a objetos

50

The Composite Reuse Principle

Mesmo exemplo utilizando composição e CRP:

Page 51: Fundamentos e princípios do projeto orientado a objetos

51

The Composite Reuse Principle

Outro exemplo com herança:

Page 52: Fundamentos e princípios do projeto orientado a objetos

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?

Mas...

Page 53: Fundamentos e princípios do projeto orientado a objetos

53

The Composite Reuse Principle

Page 54: Fundamentos e princípios do projeto orientado a objetos

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 interfaces

Page 55: Fundamentos e princípios do projeto orientado a objetos

55

The Interface Segregation Principle

Page 56: Fundamentos e princípios do projeto orientado a objetos

56

The Interface Segregation Principle

Page 57: Fundamentos e princípios do projeto orientado a objetos

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 Patternshttp://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

Domain Driven Design Quicklyhttp://www.infoq.com/minibooks/domain-driven-design-quickly

Contratos Nuloshttp://fragmental.com.br/wiki/index.php/Contratos_Nulos

Page 58: Fundamentos e princípios do projeto orientado a objetos

58

Referências

Lei de Demeterhttp://c2.com/cgi/wiki?LawOfDemeter

Articles for Object Oriented Designhttp://www.objectmentor.com/resources/publishedArticles.html