Prof. Dr. Marcos Kalinowski kalinowski@uva.

br

Apenas uma notao para diagramao orientada a objetos. Trivial e relativamente pouco importante. No um mtodo, processo ou guia de projeto.

Saber como ler e desenhar diagramas UML essencial, mas apenas um primeiro passo para elaborar bons projetos orientados a objeto.

Importante mesmo so habilidades de projeto de objetos, no saber desenhar os diagramas UML ou conhecer ferramentas CASE.
3

Uma habilidade crtica projetar e pensar em objetos. Isto pode ser praticado com base em princpios explicveis. Projeto de objetos normalmente feito do ponto de vista da metfora de: Em PGR fazemos o projeto de objetos de modo que perguntamos questes como:
Quais so as responsabilidades deste objeto? Com quem este objeto colabora? Objetos possuem responsabilidades; Objetos colaboram.

Padres so pares nomeados de problemasoluo, para problemas comuns, tipicamente mostrando uma soluo popular e robusta.
Faade (Fachada) Information Expert (Especialista na Informao)

Provem um vocabulrio de projeto.

Padres so um modo de denominar e explicar idias de projeto OO.

GRASP para princpios de Projeto OO; GoF para idias mais avanadas de projeto.

Novo Padro uma contradio.

O termo padro sugere algo longamente repetido; A idia de padres de projeto no expressar idias novas de projeto; Grandes padres tentam codificar conhecimentos e princpios existentes, testados e verdadeiros.
6

Que princpios nos guiam e ajudam a atribuir responsabilidades? Estes princpios so capturados nos padres GRASP.
General Responsibility Assignment Software Patterns. Princpios fundamentais e bsicos de projeto de objetos.

1. 2. 3. 4. 5. 6. 7. 8. 9.

Especialista na Informao (Information Expert) Criador (Creator) Controlador (Controller) Baixo Acoplamento (Low Coupling) Alta Coeso (High Cohesion) Polimorfismo (Polymorphism) Inveno Pura (Pure Fabrication) Indireo (Indirection) Variaes Protegidas (Protected Variations)

Problema: Qual o princpio geral mais bsico a respeito de atribuio de responsabilidades? Soluo (Sugesto): Atribua a responsabilidade classe que tenha informao necessria para satisfaz-la.
Quem tem a informao realiza o trabalho.

Que objeto de software calcula a taxa de venda?

1. Que informao necessria para fazer isto? 2. Que objeto tem a maior parte desta informao?

10

11

Que classe dever conter o mtodo getSquare(name)?

12

Problema: Que objeto cria um objeto X?

Ignore padres de casos especiais como Factory.

Soluo (Sugesto): Escolha um objeto C, tal que:

C C C C contm ou agrega X de forma composta; registra X; utiliza X de maneira muito prxima; tem os dados para inicializar X.

13

14

Que classe dever criar a classe Square?

15

Problema: Como reduzir o impacto de modificao? Soluo (Sugesto): Atribuir responsabilidades de modo que acoplamento permanea baixo. Use esse princpio para avaliar alternativas.

16

Utilizado tanto para escolher entre novas alternativas como para avaliar projetos existentes. Todo o resto permanecendo igual, deveramos preferir um projeto cujo acoplamento mais baixo do que as alternativas.

17

18

A classe co (outra classe arbitrria) teria que colaborar com a classe tabuleiro para obter a coleo de todas as casas de um tabuleiro. Acoplamento baixo tende a reduzir o esforo e defeitos na modificao de software. Especialista apia o acoplamento baixo.
Porque?

19

Problema: Qual o primeiro objeto, alm da IU, que recebe e coordena uma operao do sistema? Soluo (Sugesto): Atribuir a responsabilidade a um objeto que representa uma das escolhas:

Representa todo o sistema, um objeto raiz, um dispositivo dentro do qual o software est sendo executado, ou um subsistema importante (todas essas so variaes de um controlador fachada); Representa um caso de uso dentro do qual a operao do sistema ocorre (um objeto para controlar o caso de uso).

20

10

Porque no utilizar a prpria IU?

Princpio de separao entre modelo-viso.

Porque esse princpio bom?

21

22

11

A janela (JFrame) precisa delegar a mensagem recebida do ator para um objeto da camada de domnio. Para qual?

23

24

12

25

A soluo dada razovel se existem apenas poucas operaes no sistema... Caso contrrio melhor utilizar classes que representem ou controlem o caso de uso. Normalmente tais classes recebem nomes com prefixos como Tratador, Controlador, Caso...

TratadorJogarBancoImobilirio

26

13

Problema: Como manter os objetos focados, inteligveis e gerenciveis e, como efeito colateral, apoiar Baixo Acoplamento? Soluo (Sugesto): Atribuir responsabilidades de modo que a coeso permanea alta. Use isto para avaliar alternativas.

27

Coeso mede informalmente quo relacionadas funcionalmente as operaes de uma classe. Uma classe com 100 mtodos e 2000 linhas est fazendo muito mais do que uma classe com 10 mtodos e 200 linhas;
Se a classe grande est cobrindo diferentes reas de responsabilidade (acesso a bancos de dados, clculo de taxas, etc) ento esta possui pouca coeso funcional.

28

14

29

Baixa coeso e acoplamento alto esto fortemente relacionados.

Porque?

30

15

1. 2. 3. 4. 5. 6. 7. 8. 9.

Especialista na Informao (Information Expert) Criador (Creator) Controlador (Controller) Baixo Acoplamento (Low Coupling) Alta Coeso (High Cohesion) Polimorfismo (Polymorphism) Inveno Pura (Pure Fabrication) Indireo (Indirection) Variaes Protegidas (Protected Variations)

31

Marcos Kalinowski mk@kalisoftware.com

32

16

Criador. No diagrama a seguir, quem deve ser responsvel pela criao de uma instncia de SalesLineItem?

33

34

17

Especialista da Informao. Quem deve ser responsvel por conhecer o total geral de uma venda?

35

36

18

Classe de Projeto Sale SalesLineItem

Responsabilidade Sabe o total da venda Sabe o subtotal da linha de item

ProductDescription

Sabe o preo do produto

37

Especialista da Informao. Discusso;

Especialista expressa a intuio comum de que objetos fazem coisas relacionadas informao que tm.

38

19

Controlador.
No exemplo do slide a seguir, de uma registradora de vendas quem deveria controlar a execuo da operao enterItem?

39

presses button

40

20

41

Pelo controlador:
Registradora

Representa o sistema global, objeto raiz, dispositivo ou subsistema

Representa um receptor ou TratadorDeProcessarVenda tratador de todos os eventos SessoDeProcessarVenda do sistema em um cenrio de caso de uso
42

21

Coeso Alta. Discusso;

Coeso alta um princpio de avaliao que o projetista aplica quando avalia decises de projeto. Coeso Alta e Baixo Acoplamento, o yin e yang da engenharia de software?

43

1. 2. 3. 4. 5. 6. 7. 8. 9.

Especialista na Informao (Information Expert) Criador (Creator) Controlador (Controller) Baixo Acoplamento (Low Coupling) Alta Coeso (High Cohesion) Polimorfismo (Polymorphism) Inveno Pura (Pure Fabrication) Indireo (Indirection) Variaes Protegidas (Protected Variations)

44

22

Problema: Como tratar alternativas com base no tipo? Como criar componentes de software interconectveis? Soluo: Quando alternativas ou comportamentos relacionados variam segundo o tipo (classe):
Atribua a responsabilidade pelo comportamento aos tipos para os quais o comportamento varia, usando operaes polimrficas.
45

Corolrio: No teste o tipo de um objeto e use lgica condicional (if, case, etc) para executar alternativas que variam com base no tipo.

46

23

Exemplos
Banco Imobilirio:
Como projetar diferentes aes de casa? H aes diferentes ao atingir diferentes casas do tabuleiro.
Como tratar isto?

47

O que no fazer:
A classe Casa poderia ter um atributo tipo e o seguinte mtodo: public atingida(){
if (tipo == 1){ // Casa de partida } if (tipo == 2){ // Casa de imposto de renda } ...

48

24

que fazer:

49

Como isso vai funcionar na prtica?

50

25

51

52

26

53

54

27

Vantagens:

Extenses necessrias para novas variaes so fceis de adicionar. Novas implementaes podem ser introduzidas sem afetar os clientes.

Vrios padres GoF (Gamma et al., 1995) se apiam no polimorfismo.

55

Problema:
Que objeto deve ter a responsabilidade quando no se quer violar a Coeso Alta e o Acoplamento Baixo ou outros objetivos, mas as solues oferecidas pelo Especialista (por exemplo) no so apropriadas?

56

28

H situaes em que atribuir responsabilidades apenas a classes de software da camada de domnio leva a problemas em termos de coeso ou acoplamento inadequados ou baixo potencial de reuso.

57

Soluo: Atribuir um conjunto de responsabilidades altamente coeso a uma classe artificial ou de convenincia que no represente um conceito no domnio do problema algo inventado para apoiar coeso alta, acoplamento baixo e reuso. Idealmente as responsabilidades atribudas a esta inveno apiam coeso alta e acoplamento baixo, de modo que o projeto da inveno seja muito limpo ou puro.
58

29

Exemplo:
Jogador lanava os dados e fazia a soma dos valores. Servio de somar no generalizvel para outros jogadores; No era guardado o total do ltimo lanamento da partida. Por

inveno pura

59

60

30

Exemplo:
Classe

para tratar a Persistncia de objetos em um banco de dados. Com mtodos como:

inserir (Objeto) atualizar (Objeto) ...

Essa

classe no faz parte do domnio do problema, mas relativamente coesa, genrica e reutilizvel. os Padres GoF so invenes puras.
61

Todos

Problema:
A quem devemos atribuir a responsabilidade de maneira a evitar o acoplamento direto entre objetos (ou componentes)?

Soluo:
Atribuir a responsabilidade de ser o mediador entre outros componentes e servios a um objeto intermedirio, para que eles no sejam diretamente acoplados.

O intermedirio cria indireo entre os outros componentes.

62

31

Exemplo: Uso de um adaptador.

63

Exemplo 2:
Classe para tratar a Persistncia de objetos em um banco de dados. Com mtodos como:
inserir (Objeto) atualizar (Objeto) ...

Esta classe tambm um exemplo de Indireo, afinal a classe age como intermedirio entre as demais classes e o banco de dados.

64

32

Problema:
Como projetar objetos, subsistemas e sistemas de modo que as variaes ou instabilidades nesses elementos no tenham um impacto indesejvel sobre outros elementos?

Soluo:
Identificar pontos de variao ou instabilidade previsvel; atribuir responsabilidades para criar uma interface estvel em torno deles.

65

Este um princpio fundamental muito importante de projeto de software. Quase todo truque de projeto de software ou arquitetural trata de tipos de variao protegida; importante saber que batalhas de Variaes Protegidas vale a pena travar.

66

33

Prof. Dr. Marcos Kalinowski kalinowski@uva.br

67

umObjeto.obterFoo().executar();

Lei de Demeter, No fale com estranhos!! umObjeto.executarEmFoo();

68

34

O diagrama de classes a seguir foi criado por um projetista que no fez o nosso curso e possui acoplamento bastante acima do ideal, dificultando a manuteno. Voc foi contratado para resolver este problema.

69

banco.getAgencia(idAg).getContaCorrente(idCc).cadastraConta();

70

35

Prof. Dr. Marcos Kalinowski kalinowski@uva.br

71

Padres de soluo advm de padres nos problemas

Um padro representa um equilbrio de foras As foras so as caractersticas que afetam um problema O projeto do sistema realiza trade-offs entre estas foras Os padres de projeto tornam este trade-off explcito

72

36

Problema:
Determina quando o padro deve ser utilizado

Soluo:
Determina o que fazer para resolver o problema

Contexto:
Caractersticas da situao em que o padro se aplica

Foras:
Vantagens e desvantagens da aplicao do padro

Conseqncias:
Positivas e negativas de aplicao do padro
73

Encontrando o equilbrio entre as foras

74

37

Padres GoF
Organizaes entre classes e a forma com que estas classes interagem para resolver um problema recorrente

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

Christopher Alexander

75

Creational patterns
Abstract factory Builder Factory method Prototype Singleton

Behavioral Patterns

Structural patterns
Adapter Bridge Composite Decorator Facade Flyweight Proxy

Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

76

38

Creational patterns
Abstract factory Builder Factory method Prototype Singleton

Behavioral Patterns

Structural patterns
Adapter Bridge Composite Decorator Facade Flyweight Proxy

Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

77

78

39

Problema:
Alguns objetos complexos podem exigir um grande trabalho para sua instanciao e preparao para uso Objetos formados por diversos componentes, que podem ser configurados em diferentes ordens Como podemos isolar a instanciao e setup de um objeto complexo?

Soluo:
Cria uma classe que separe a criao de um objeto de sua representao, de forma que o processo de criao possa ser utilizado para formar representaes distintas

79

Implementao
Cria uma classe responsvel pelo processo de criao dos objetos complexos e seus componentes A classe de construo pode ser abstrata, com subclasses concretas responsveis por construir a partir de uma hierarquia de componentes (ver Abstract Factory)

Conseqncias
A complexidade de criao dos objetos encapsulado na classe construtora Os objetos mais simples podem ser organizados em diversas ordens pela classe construtora

80

40

Cliente

Builder ConstroiProduto () ConstroiParte ()

Produto

Parte do Produto

Cliente

Builder Abstrato ConstroiProduto () ConstroiParte () Produto

Parte do Produto BuilderConcreto ConstroiProduto () ConstroiParte ()

81

82

41

Problema
O encapsulamento funciona para uma classe, mas seria desejvel possuir uma interface bem definida para um subsistema complexo (vrias classes) A interface esconderia os detalhes do subsistema, de forma que este pudesse ser utilizado sem conhecimento de sua implementao

Soluo
Criar uma classe que representa a interface com o subsistema (fachada visvel do subsistema) Fazer com que o cliente dependa apenas desta classe e no acesse as classes do subsistema para utilizar seus servios

83

Implementao
A fachada pode atender a uma interface, possibilitando mltiplas implementaes da interface com o subsistema Questes: as classes internas do subsistema so visveis externamente? Somente as classes de dados? Cuidado com a utilizao extrema de padres: lembre-se que o objetivo principal de um projeto no usar padres !!!

Conseqncias
Maior reusabilidade no subsistema, que est independente dos clientes Maior reusabilidade no cliente, que depende apenas da interface definida na fachada
84

42

Fachada Cliente Operao1 () Operao2 () ... OperaoN ()

Classes do Subsistema
85

86

43

Problema
Alguns sistemas possibilitam a utilizao de uma famlia de algoritmos equivalentes O algoritmo em particular que ir operar sobre um conjunto de dados depende de caractersticas destes dados

Soluo
Os algoritmos devem ser encapsulados e facilmente substitudos Os algoritmos podem ser substitudos dinamicamente em tempo de execuo Dados especficos de cada algoritmo podem ser mantidos em suas respectivas implementaes

87

Implementao
Uma classe abstrata implementa a interface de acesso aos algoritmos Classes concretas herdam da classe abstrata, implementando cada algoritmo da famlia

Conseqncias
Maior nmero de objetos Clientes precisam estar cientes das diferentes estratgias

88

44

Lista Atividades adicionaAtividade (a) procuraAtividade (nome)

Estratgia Abstrata procura (lista, nome)

Estratgia Inicio Fim procura (lista, nome)

Estratgia Fim Inicio procura (lista, nome)

Classe cliente da estratgia: quer utilizar o servio independente de sua implementao

Classes concretas: solues especficas para o problema

Classe abstrata: representa qualquer soluo para o problema

89

90

45

Prof. Dr. Marcos Kalinowski kalinowski@uva.br

91

Refatorao o processo de alterao de um sistema de software de modo que o comportamento externo do cdigo no mude, mas que sua estrutura interna seja melhorada. uma maneira disciplinada de aperfeioar o cdigo que minimiza a chance de introduo de falhas. Em essncia, quando voc usa refatorao, voc est melhorando o projeto do cdigo aps este ter sido escrito.

92

46

93

Duas subclasses tm o mesmo atributo

Mova o atributo para a superclasse

94

47

95

96

48

Mtodos nas subclasses produzindo resultados idnticos Mova-os para a superclasse.

Motivao: Evitar a duplicao de cdigo

97

O mtodo createBill idntico para ambas as classes

98

49

Problema: No posso mover o mtodo createBill na hierarquia porque o mtodo chargeFor diferente em cada subclasse Soluo: declarar o mtodo chargeFor como abstrato na superclasse

99

10 0

50

Uma subclasse usa apenas parte da interface de uma superclasse ou no quer herdar dados. Crie um campo para a superclasse, ajuste mtodos para delegarem para a superclasse e remova a herana. Motivao

A subclasse usa somente parte da interface da superclasse Problema conceitual: a subclasse no do tipo da superclasse
101

10 2

51

10 3

10 4

52

Voc est usando delegao e est freqentemente escrevendo muitas delegaes simples para toda a interface. Torne a classe que delega uma subclasse da classe delegada. Motivao

Este o reverso de Substituir Herana por Delegao. Se voc se encontrar usando todos os mtodos da classe delegada e estiver farto de escrever todos esses mtodos de delegao simples, pode voltar para a herana facilmente.

105

10 6

53

10 7

O livro das refatoraes

Fowler, M., Refatorao Aperfeioando o Projeto de Cdigo Existente, Editora Bookman, 2004.

A pgina das refatoraes

www.refactoring.com Mantida por Martin Fowler.

10 8

54