Caelum java-testes-jsf-web-services-design-patterns-fj22

Conheça mais da Caelum.
Cursos Online
www.caelum.com.br/online

Casa do Código
Livros para o programador
www.casadocodigo.com.br

Blog Caelum
blog.caelum.com.br

Newsletter
www.caelum.com.br/newsletter

Facebook
www.facebook.com/caelumbr

Twitter
twitter.com/caelum

Sobre esta apostila
Esta apostila da Caelum visa ensinar de uma maneira elegante, mostrando apenas o que é necessário e quando
é necessário, no momento certo, poupando o leitor de assuntos que não costumam ser de seu interesse em
determinadas fases do aprendizado.
A Caelum espera que você aproveite esse material. Todos os comentários, críticas e sugestões serão muito
bem-vindos.
Essa apostila é constantemente atualizada e disponibilizada no site da Caelum. Sempre consulte o site para
novas versões e, ao invés de anexar o PDF para enviar a um amigo, indique o site para que ele possa sempre
baixar as últimas versões. Você pode conferir o código de versão da apostila logo no final do índice.
Baixe sempre a versão mais nova em: www.caelum.com.br/apostilas
Esse material é parte integrante do treinamento Laboratório Java com Testes, JSF, Web Services e Design
Patterns e distribuído gratuitamente exclusivamente pelo site da Caelum. Todos os direitos são reservados à
Caelum. A distribuição, cópia, revenda e utilização para ministrar treinamentos são absolutamente vedadas.
Para uso comercial deste material, por favor, consulte a Caelum previamente.
www.caelum.com.br

1

Sumário
1

2

3

Tornando-se um desenvolvedor pragmático
1.1 O que é realmente importante? . . . . .
1.2 A importância dos exercícios . . . . . .
1.3 Tirando dúvidas e referências . . . . . .
1.4 Para onde ir depois? . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

O modelo da bolsa de valores, datas e objetos imutáveis
2.1 A bolsa de valores . . . . . . . . . . . . . . . . . . . . .
2.2 Candlesticks: O Japão e o arroz . . . . . . . . . . . . .
2.3 O projeto Tail . . . . . . . . . . . . . . . . . . . . . . .
2.4 O projeto Argentum: modelando o sistema . . . . . .
2.5 Trabalhando com dinheiro . . . . . . . . . . . . . . . .
2.6 Palavra chave final . . . . . . . . . . . . . . . . . . . . .
2.7 Imutabilidade de objetos . . . . . . . . . . . . . . . . .
2.8 Trabalhando com datas: Date e Calendar . . . . . . .
2.9 Exercícios: o modelo do Argentum . . . . . . . . . . .
2.10 Resumo diário das Negociações . . . . . . . . . . . . .
2.11 Exercícios: fábrica de Candlestick . . . . . . . . . . . .
2.12 Exercícios opcionais . . . . . . . . . . . . . . . . . . . .
Testes Automatizados
3.1 Nosso código está funcionando corretamente? . . . .
3.2 Exercícios: testando nosso modelo sem frameworks .
3.3 Definindo melhor o sistema e descobrindo mais bugs
3.4 Testes de Unidade . . . . . . . . . . . . . . . . . . . . .
3.5 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Anotações . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 JUnit4, convenções e anotação . . . . . . . . . . . . .
3.8 Exercícios: migrando os testes do main para JUnit . .
3.9 Vale a pena testar classes de modelo? . . . . . . . . . .
3.10 Exercícios: novos testes . . . . . . . . . . . . . . . . . .
3.11 Para saber mais: Import Estático . . . . . . . . . . . .
3.12 Mais exercícios opcionais . . . . . . . . . . . . . . . .
3.13 Discussão em aula: testes são importantes? . . . . . .

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

1
1
2
3
3

.
.
.
.
.
.
.
.
.
.
.
.

4
4
5
6
8
9
9
10
12
15
23
24
27

.
.
.
.
.
.
.
.
.
.
.
.
.

30
30
30
33
33
34
35
36
38
43
44
49
50
50

4 Trabalhando com XML
51
4.1 Os dados da bolsa de valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 O formato XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Lendo XML com Java de maneira difícil, o SAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
i

4.4
4.5
4.6
5

XStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Exercícios: Lendo o XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Discussão em aula: Onde usar XML e o abuso do mesmo . . . . . . . . . . . . . . . . . . . . . . 62

Test Driven Design - TDD
5.1 Separando as candles . . . . . . . . . . . . . . . . . . .
5.2 Vantagens do TDD . . . . . . . . . . . . . . . . . . . .
5.3 Exercícios: Identificando negociações do mesmo dia
5.4 Exercícios: Separando os candles . . . . . . . . . . . .
5.5 Exercícios opcionais . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

6 Acessando um Web Service
6.1 Integração entre sistemas . . . . . . . . . . . . . . . . . . . .
6.2 Consumindo dados de um Web Service . . . . . . . . . . .
6.3 Criando o cliente Java . . . . . . . . . . . . . . . . . . . . . .
6.4 Exercícios: Nosso cliente Web Service . . . . . . . . . . . .
6.5 Discussão em aula: Como testar o cliente do web service?
7

8

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

63
63
64
65
67
69

.
.
.
.
.

72
72
72
73
76
77

Introdução ao JSF e Primefaces
7.1 Interfaces gráficas para o usuário - GUI . . . . . . . . . . . . . . . .
7.2 O cliente gordo e o desenvolvimento Desktop . . . . . . . . . . . .
7.3 O desenvolvimento Web e o protocolo HTTP . . . . . . . . . . . .
7.4 Mesclar desenvolvimento Desktop e Web . . . . . . . . . . . . . . .
7.5 Especificação e implementação do JSF . . . . . . . . . . . . . . . . .
7.6 Introdução ao JSF com Mojarra e PrimeFaces . . . . . . . . . . . .
7.7 Preparação do ambiente . . . . . . . . . . . . . . . . . . . . . . . . .
7.8 Exercícios: Instalando o Tomcat e criando o projeto . . . . . . . . .
7.9 A primeira página com JSF 2 . . . . . . . . . . . . . . . . . . . . . .
7.10 Exercícios: Os primeiros componentes JSF . . . . . . . . . . . . . .
7.11 Listagem de Negociações com Primefaces . . . . . . . . . . . . . . .
7.12 Código atrás da tela - Managed Beans . . . . . . . . . . . . . . . . .
7.13 Formatação de Data com JSF . . . . . . . . . . . . . . . . . . . . . .
7.14 Paginação e Ordenação das negociações . . . . . . . . . . . . . . . .
7.15 Exercícios: p:dataTable para listar as Negociações do Web Service .
7.16 O Padrão Model View Controller . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

78
78
79
80
81
81
82
85
86
94
96
98
99
101
102
103
106

Refatoração: os Indicadores da bolsa
8.1 Análise Técnica da bolsa de valores
8.2 Indicadores Técnicos . . . . . . . .
8.3 As médias móveis . . . . . . . . . .
8.4 Exercícios: criando indicadores . .
8.5 Refatoração . . . . . . . . . . . . . .
8.6 Exercícios: Primeiras refatorações

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

108
108
109
110
113
117
118

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

ii

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

8.7
8.8

Refatorações maiores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Discussão em aula: quando refatorar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

9 Gráficos interativos com Primefaces
9.1 Por que usar gráficos? . . . . . . . . . . . . . . . . . . . . . . .
9.2 Exemplos de Gráficos . . . . . . . . . . . . . . . . . . . . . . .
9.3 Utilizando o Primefaces . . . . . . . . . . . . . . . . . . . . .
9.4 Propriedades para personalizar o gráfico . . . . . . . . . . .
9.5 Definição do modelo do gráfico . . . . . . . . . . . . . . . . .
9.6 Isolando a API do Primefaces: baixo acoplamento . . . . . .
9.7 Para saber mais: Design Patterns Factory Method e Builder
9.8 Exercícios: Gráficos com Primefaces . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

10 Aplicando Padrões de projeto
10.1 Nossos indicadores e o design pattern Strategy . . . . . . . . . . . . .
10.2 Exercícios: refatorando para uma interface e usando bem os testes .
10.3 Exercícios opcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4 Indicadores mais Elaborados e o Design Pattern Decorator . . . . . .
10.5 Exercícios: Indicadores mais espertos e o Design Pattern Decorator
11 Formulários com JSF
11.1 Melhorando a Interface . . . . . . . . . . . . . . . . .
11.2 Componentes de entrada . . . . . . . . . . . . . . . .
11.3 Submetendo o formulário . . . . . . . . . . . . . . .
11.4 Validação com JSF . . . . . . . . . . . . . . . . . . . .
11.5 Organização dos componentes . . . . . . . . . . . .
11.6 Exercícios: Executando lógica e validando entrada .
11.7 ComboBox para selecionar os indicadores . . . . .
11.8 Exercícios: Completando o Formulário . . . . . . .
12 API de Reflection
12.1 Montando os indicadores dinamicamente
12.2 Introdução a Reflection . . . . . . . . . . .
12.3 Por que Reflection? . . . . . . . . . . . . .
12.4 Constructor, Field e Method . . . . . . . .
12.5 Melhorando nosso ArgentumBean . . . .
12.6 Exercícios: Plotando indicadores . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

13 Apêndice Testes de interface com Selenium
13.1 Introdução ao teste de aceitação . . . . . . . . . . . .
13.2 Como funciona? . . . . . . . . . . . . . . . . . . . . .
13.3 Trabalhando com diversos testes de aceitação . . . .
13.4 Para saber mais: Configurando o Selenium em casa

iii

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

123
123
123
124
125
127
129
132
133

.
.
.
.
.

136
136
139
142
142
144

.
.
.
.
.
.
.
.

146
146
146
147
149
150
152
154
156

.
.
.
.
.
.

158
158
160
160
161
163
167

.
.
.
.

172
172
172
175
176

13.5 Exercícios: Teste com Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Índice Remissivo

180
Versão: 16.5.25

iv

Capítulo 1

Tornando-se um desenvolvedor pragmático
“Na maioria dos casos, as pessoas, inclusive os facínoras, são muito mais ingênuas e simples do que
costumamos achar. Aliás, nós também.”
– Fiodór Dostoiévski, em Irmãos Karamazov
Por que fazer esse curso?

1.1

O que é realmente importante?

Você já passou pelo FJ-11 e, quem sabe, até pelo FJ-21. Agora chegou a hora de codificar bastante para pegar
os truques e hábitos que são os grandes diferenciais do programador Java experiente.
Pragmático é aquele que se preocupa com as questões práticas, menos focado em ideologias e tentando
colocar a teoria pra andar.
Esse curso tem como objetivo trazer uma visão mais prática do desenvolvimento Java através de uma experiência rica em código, onde exercitaremos diversas APIS e recursos do Java. Vale salientar que as bibliotecas
em si não são os pontos mais importantes do aprendizado neste momento, mas sim as boas práticas, a cultura
e um olhar mais amplo sobre o design da sua aplicação.
Os design patterns, as boas práticas, a refatoração, a preocupação com o baixo acoplamento, os testes de unidade (também conhecidos como testes unitários) e as técnicas de programação (idiomismos) são passados
com afinco.
Para atingir tal objetivo, esse curso baseia-se fortemente em artigos, blogs e, em especial, na literatura que se
consagrou como fundamental para os desenvolvedores Java. Aqui citamos alguns desses livros:
http://blog.caelum.com.br/2006/09/22/livros-escolhendo-a-trindade-do-desenvolvedor-java/

Material do Treinamento Laboratório Java com Testes, JSF, Web Services e Design Patterns

Somamos a esses mais dois livros, que serão citados no decorrer do curso, e influenciaram muito na elaboração do conteúdo que queremos transmitir a vocês. Todos os cinco são:
• Effective Java, Joshua Bloch Livro de um dos principais autores das maiores bibliotecas do Java SE
(como o java.io e o java.util), arquiteto chefe Java na Google atualmente. Aqui ele mostra como enfrentar os principais problemas e limitações da linguagem. Uma excelente leitura, dividido em mais de 70
tópicos de 2 a 4 páginas cada, em média. Entre os casos interessantes está o uso de factory methods, os
problemas da herança e do protected, uso de coleções, objetos imutáveis e serialização, muitos desses
abordados e citados aqui no curso.
• Design Patterns, Erich Gamma et al Livro de Erich Gamma, por muito tempo líder do projeto Eclipse
na IBM, e mais outros três autores, o que justifica terem o apelido de Gang of Four (GoF). Uma excelente leitura, mas cuidado: não saia lendo o catálogo dos patterns decorando-os, mas concentre-se
especialmente em ler toda a primeira parte, onde eles revelam um dos princípios fundamentais da
programação orientada a objetos:“Evite herança, prefira composição” e “Programe voltado às interfaces
e não à implementação”.
• Refactoring, Martin Fowler Livro do cientista chefe da ThoughtWorks. Um excelente catálogo de
como consertar pequenas falhas do seu código de maneira sensata. Exemplos clássicos são o uso de
herança apenas por preguiça, uso do switch em vez de polimorfismo, entre dezenas de outros. Durante
o curso, faremos diversos refactoring clássicos utilizando do Eclipse, muito mais que o básico rename.
• Pragmatic Programmer, Andrew Hunt As melhores práticas para ser um bom desenvolvedor: desde
o uso de versionamento, ao bom uso do logging, debug, nomenclaturas, como consertar bugs, etc.
• The mythical man-month, Frederick Brooks Um livro que fala dos problemas que encontramos
no dia a dia do desenvolvimento de software, numa abordagem mais gerencial. Aqui há, inclusive, o
clássico artigo “No Silver Bullet”, que afirma que nunca haverá uma solução única (uma linguagem,
um método de desenvolvimento, um sistema operacional) que se adeque sempre a todos os tipos de
problema.

1.2

A importância dos exercícios

É um tanto desnecessário debater sobre a importância de fazer exercícios, porém neste curso específico eles
são vitais: como ele é focado em boas práticas, alguma parte da teoria não está no texto - e é passado no
decorrer de exercícios.
Não se assuste, há muito código aqui nesse curso, onde vamos construir uma pequena aplicação que lê um
XML com dados da bolsa de valores e plota o gráfico de candlesticks, utilizando diversas APIs do Java SE e
até mesmo bibliotecas externas.

Capítulo 1 - Tornando-se um desenvolvedor pragmático - A importância dos exercícios - Página 2


1.3

Tirando dúvidas e referências

Para tirar dúvidas dos exercícios, ou de Java em geral, recomendamos o fórum do site do GUJ (http://www.
guj.com.br/), onde sua dúvida será respondida prontamente.
Fora isso, sinta-se à vontade para entrar em contato com seu instrutor e tirar todas as dúvidas que tiver
durante o curso.
Você pode estar interessado no livro TDD no mundo real, da editora Casa do Código:
http://www.tddnomundoreal.com.br/

1.4

Para onde ir depois?

Se você se interessou pelos testes, design e automação, recomendamos os cursos online de testes da Caelum:
http://www.caelum.com.br/curso/online/testes-automatizados/
O FJ-21 é indicado para ser feito antes ou depois deste curso, dependendo das suas necessidades e do seu
conhecimento. Ele é o curso que apresenta o desenvolvimento Web com Java e seus principais ferramentas
e frameworks.
Depois destes cursos, que constituem a Formação Java da Caelum, indicamos dois outros cursos, da Formação Avançada:
http://www.caelum.com.br/formacao-java-avancada/
O FJ-25 aborda Hibernate e JPA 2 e o FJ-26 envolve JSF 2, Facelets e CDI. Ambos vão passar por tecnologias
hoje bastante utilizadas no desenvolvimento server side para web, e já na versão do Java EE 6.

Capítulo 1 - Tornando-se um desenvolvedor pragmático - Tirando dúvidas e referências - Página 3

Capítulo 2

O modelo da bolsa de valores, datas e objetos
imutáveis
“Primeiro aprenda ciência da computação e toda a teoria. Depois desenvolva um estilo de programação. E aí
esqueça tudo e apenas ‘hackeie’."
– George Carrette
O objetivo do FJ-22 é aprender boas práticas da orientação a objetos, do design de classes, uso correto dos
design patterns, princípios de práticas ágeis de programação e a importância dos testes de unidade.
Dois livros que são seminais na área serão referenciados por diversas vezes pelo instrutor e pelo material:
Effective Java, do Joshua Bloch, e Design Patterns: Elements of Reusable Object-Oriented Software, de Erich
Gamma e outros (conhecido Gang of Four).

2.1

A bolsa de valores

Poucas atividades humanas exercem tanto fascínio quanto o mercado de ações, assunto abordado exaustivamente em filmes, livros e em toda a cultura contemporânea. Somente em novembro de 2007, o total
movimentado pela BOVESPA foi de R$ 128,7 bilhões. Destes, o volume movimentado por aplicações home
broker foi de R$ 22,2 bilhões.
Neste curso, abordaremos esse assunto que, hoje em dia, chega a ser cotidiano desenvolvendo uma aplicação
que interpreta os dados de um XML, trata e modela eles em Java e mostra gráficos pertinentes.


2.2

Candlesticks: O Japão e o arroz

Yodoya Keian era um mercador japonês do século 17. Ele se tornou rapidamente muito rico, dadas as suas
habilidades de transporte e precificação do arroz, uma mercadoria em crescente produção em consumo no
país. Sua situação social de mercador não permitia que ele fosse tão rico dado o sistema de castas da época e,
logo, o governo confiscou todo seu dinheiro e suas posses. Depois dele, outros vieram e tentaram esconder
suas origens como mercadores: muitos tiveram seus filhos executados e seu dinheiro confiscado.
Apesar da triste história, foi em Dojima, no jardim do próprio Yodoya Keian, que nasceu a bolsa de arroz
do Japão. Lá eram negociados, precificados e categorizados vários tipos de arroz. Para anotar os preços do
arroz, desenhava-se figuras no papel. Essas figuras parecem muito com velas -- daí a analogia candlestick.
Esses desenhos eram feitos em um papel feito de... arroz! Apesar de usado a séculos, o mercado ocidental só
se interessou pela técnica dos candlesticks recentemente, no último quarto de século.
Um candlestick indica 4 valores: o maior preço do dia, o menor preço do dia (as pontas), o primeiro preço
do dia e o último preço do dia (conhecidos como abertura e fechamento, respectivamente).
Os preços de abertura e fechamento são as linhas horizontais e dependem do tipo de candle: se for de alta, o
preço de abertura é embaixo; se for de baixa, é em cima. Um candle de alta costuma ter cor azul ou branca
e os de baixa costumam ser vermelhos ou pretos. Caso o preço não tenha se movimentado, o candle tem a
mesma cor que a do dia anterior.
Para calcular as informações necessárias para a construção de um Candlestick, são necessários os dados de
todos as negociações (trades) de um dia. Uma Negociação possui três informações: o preço pelo qual foi
comprado, a quantidade de ativos e a data em que ele foi executado.

Você pode ler mais sobre a história dos candles em: http://www.candlestickforum.com/PPF/Parameters/1_
279_/candlestick.asp
Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Candlesticks: O Japão e o arroz - Página 5


Apesar de falarmos que o Candlestick representa os principais valores de um dia, ele pode ser usado para
os mais variados intervalos de tempo: um candlestick pode representar 15 minutos, ou uma semana, dependendo se você está analisando o ativo para curto, médio ou longo prazo.

2.3

O projeto Tail

A ideia do projeto Tail (Technical Analysis Indicator Library) nasceu quando um grupo de alunos da Universidade de São Paulo procurou o professor doutor Alfredo Goldman para orientá-los no desenvolvimento
de um software para o projeto de conclusão de curso.
Ele então teve a ideia de juntar ao grupo alguns alunos do mestrado através de um sistema de coorientação,
onde os mestrandos auxiliariam os graduandos na implementação, modelagem e metodologia do projeto.
Somente então o grupo definiu o tema: o desenvolvimento de um software open source de análise técnica
grafista (veremos o que é a análise técnica em capítulos posteriores).
O software está disponível no SourceForge:
http://sourceforge.net/projects/tail/

Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - O projeto Tail - Página 6


Essa ideia, ainda vaga, foi gradativamente tomando a forma do projeto desenvolvido. O grupo se reunia
semanalmente adaptando o projeto, atribuindo novas tarefas e objetivos. Os graduandos tiveram a oportunidade de trabalhar em conjunto com os mestrandos, que compartilharam suas experiências anteriores.
Objetivos do projeto Tail:
• Implementar os componentes básicos da análise técnica grafista: série temporal, operações de compra
e venda e indicadores técnicos;
• Implementar as estratégias de compra e venda mais utilizadas no mercado, assim como permitir o
rápido desenvolvimento de novas estratégias;
• Implementar um algoritmo genérico para determinar um momento apropriado de compra e venda de
um ativo, através da escolha da melhor estratégia aplicada a uma série temporal;
• Permitir que o critério de escolha da melhor estratégia seja trocado e desenvolvido facilmente;
• Criar relatórios que facilitem o estudo e a compreensão dos resultados obtidos pelo algoritmo;
• Criar uma interface gráfica, permitindo o uso das ferramentas implementadas de forma fácil, rápida e
de simples entendimento, mas que não limite os recursos da biblioteca;
• Arquitetura orientada a objetos, com o objetivo de ser facilmente escalável e de simples entendimento;
• Utilizar práticas de XP, adaptando-as conforme as necessidades do grupo.
• Manter a cobertura de testes superior a 90%;
• Analisar o funcionamento do sistema de coorientação, com o objetivo estendê-lo para projetos futuros.
Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - O projeto Tail - Página 7


O Tail foi desenvolvido por Alexandre Oki Takinami, Carlos Eduardo Mansur, Márcio Vinicius dos Santos, Thiago Garutti Thies, Paulo Silveira (mestre em Geometria Computacional pela USP e diretor da Caelum), Julian Monteiro (mestre em sistemas distribuídos pela USP e doutor pelo INRIA, em Sophia Antipolis,
França) e Danilo Sato (mestre em Metodologias Ágeis pela USP e Lead Consultant na ThoughtWorks).
Esse projeto foi a primeira parceria entre a Caelum e a USP, onde a Caelum patrocinou o trabalho de conclusão de curso dos 4 graduandos, hoje todos formados.
Caso tenha curiosidade você pode acessar o CVS do projeto, utilizando o seguinte repositório:
http://tail.cvs.sourceforge.net/viewvc/tail/

2.4

O projeto Argentum: modelando o sistema

O projeto Tail é bastante ambicioso. Tem centenas de recursos, em especial o de sugestão de quando comprar
e de quando vender ações. O interessante durante o desenvolvimento do projeto Tail foi que muitos dos
bons princípios de orientação a objetos, engenharia de software, design patterns e Programação eXtrema se
encaixaram muito bem - por isso, nos inspiramos fortemente nele como base para o FJ-22.
Queremos modelar diversos objetos do nosso sistema, entre eles teremos:
• Negociação - guardando preço, quantidade e data;
• Candlestick - guardando as informações do Candle, além do volume de dinheiro negociado;
• SerieTemporal - que guarda um conjunto de candles.
Essas classes formarão a base do projeto que criaremos durante o treinamento, o Argentum (do latim, dinheiro ou prata). As funcionalidades do sistema serão as seguintes:
• Resumir Negociacoes em Candlesticks.Nossa base serão as negociações. Precisamos converter uma
lista de negociações em uma lista de Candles.
• Converter Candlesticks em SerieTemporal.Dada uma lista de Candle, precisamos criar uma série
temporal.
• Utilizar indicadores técnicosPara isso, implementar um pequeno framework de indicadores e criar
alguns deles de forma a facilitar o desenvolvimento de novos.
• Gerar gráficosEmbutíveis e interativos na interface gráfica em Java, dos indicadores que criamos.
Para começar a modelar nosso sistema, precisamos entender alguns recursos de design de classes que ainda
não foram discutidos no FJ-11. Entre eles podemos citar o uso da imutabilidade de objetos, uso de anotações
e aprender a trabalhar e manipular datas usando a API do Java.

Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - O projeto Argentum: modelando o sistema - Página 8


2.5

Trabalhando com dinheiro

Até agora, não paramos muito para pensar nos tipos das nossas variáveis e já ganhamos o costume de automaticamente atribuir valores a variáveis double. Essa é, contudo, uma prática bastante perigosa!
O problema do double é que não é possível especificar a precisão mínima que ele vai guardar e, dessa forma,
estamos sujeitos a problemas de arredondamento ao fracionar valores e voltar a somá-los. Por exemplo:
double cem = 100.0;
double tres = 3.0;
double resultado = cem / tres;
System.out.println(resultado);
//
33.333?
//
33.333333?
//
33.3?

Se não queremos correr o risco de acontecer um arredondamento sem que percebamos, a alternativa é usar
a classe BigDecimal, que lança exceção quando tentamos fazer uma operação cujo resultado é inexato.
Leia mais sobre ela na própria documentação do Java.

2.6

Palavra chave final

A palavra chave final tem várias utilidades. Em uma classe, define que a classe nunca poderá ter uma filha,
isso é, não pode ser estendida. A classe String, por exemplo, é final.
Como modificador de método, final indica que aquele método não pode ser reescrito. Métodos muito
importantes costumam ser definidos assim. Claro que isso não é necessário declarar caso sua classe já seja
final.
Ao usarmos como modificador na declaração de variável, indica que o valor daquela variável nunca poderá
ser alterado, uma vez atribuído. Se a variável for um atributo, você tem que inicializar seu valor durante a
construção do objeto - caso contrário, ocorre um erro de compilação, pois atributos final não são inicializados com valores default.
Imagine que, quando criamos um objeto Negociacao, não queremos que seu valor seja modificado:
class Negociacao {
private final double valor;
// getters e setters?
}
Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Trabalhando com dinheiro - Página 9


Esse código não compila, nem mesmo com um setter, pois o valor final deveria já ter sido inicializado. Para
resolver isso, ou declaramos o valor da Negociacao direto na declaração do atributo (o que não faz muito
sentido nesse caso), ou então populamos pelo construtor:
class Negociacao {
private final double valor;
public Negociacao(double valor) {
this.valor = valor;
}
// podemos ter um getter, mas nao um setter aqui!
}

Uma variável static final tem uma cara de constante daquela classe e, se for public static final, aí parece uma constante global! Por exemplo, na classe Collections do java.util existe uma constante public
static final chamada EMPTY_LIST. É convenção que constantes sejam declaradas letras maiúsculas e separadas por travessão (underscore) em vez de usar o padrão camel case. Outros bons exemplos são o PI e o E,
dentro da java.lang.Math.
Isso é muito utilizado, mas hoje no java 5 para criarmos constantes costuma ser muito mais interessante
utilizarmos o recurso de enumerações que, além de tipadas, já possuem diversos métodos auxiliares.
No caso da classe Negociacao, no entanto, bastará usarmos atributos finais e também marcarmos a própria
classe como final para que ela crie apenas objetos imutáveis.

2.7

Imutabilidade de objetos
Effective Java
Item 15: Minimize mutabilidade

Para que uma classe seja imutável, ela precisa ter algumas características:
• Nenhum método pode modificar seu estado;
• A classe deve ser final;
• Os atributos devem ser privados;
• Os atributos devem ser final, apenas para legibilidade de código, já que não há métodos que modificam o estado do objeto;
Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Imutabilidade de objetos - Página 10


• Caso sua classe tenha composições com objetos mutáveis, eles devem ter acesso exclusivo pela sua
classe.
Diversas classes no Java são imutáveis, como a String e todas as classes wrapper. Outro excelente exemplo
de imutabilidade são as classes BigInteger e BigDecimal:
Qual seria a motivação de criar uma classe de tal maneira?

Objetos podem compartilhar suas composições
Como o objeto é imutável, a composição interna de cada um pode ser compartilhada entre eles, já que não
há chances de algum deles mudar tais atributos. Esse compartilhamento educado possibilita fazer cache de
suas partes internas, além de facilitar a manipulação desses objetos.
Isso pode ser encarado como o famoso design pattern Flyweight.
É fácil entender os benefícios dessa prática quando olhamos para o caso da String: objetos do tipo String
que contêm exatamente o mesmo texto ou partes exatas do texto original (como no caso de usarmos o
substring) compartilham a array privada de chars!
Na prática, o que isso quer dizer é que se você tem uma String muito longa e cria várias outras com trechos
da original, você não terá que armazenar os caracteres de novo para cada trecho: eles utilizarão o array de
chars da String original!
String
String
String
String
String

palavra = "supercalifragilisticexpialidocious";
inicio = palavra.substring(0, 5);
proximas = palavra.substring(5, 10);
outras = palavra.substring(10, 15);
resto = palavra.substring(15);

Esses objetos também são ideais para usar como chave de tabelas de hash.

Thread safety
Uma das principais vantagens da imutabilidade é em relação a concorrência. Simplesmente não precisamos
nos preocupar em relação a isso: como não há método que mude o estado do objeto, então não há como
fazer duas modificações acontecerem concorrentemente!

Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Imutabilidade de objetos - Página 11


Objetos mais simples
Uma classe imutável é mais simples de dar manutenção. Como não há chances de seu objeto ser modificado,
você tem uma série de garantias sobre o uso daquela classe.
Se os construtores já abrangem todas as regras necessárias para validar o estado do objeto, não há preocupação em relação a manter o estado consistente, já que não há chances de modificação.
Uma boa prática de programação é evitar tocar em variáveis parâmetros de um método. Com objetos imutáveis nem existe esse risco quando você os recebe como parâmetro.
Se nossa classe Negociacao é imutável, isso remove muitas dúvidas e medos que poderíamos ter durante o
desenvolvimento do nosso projeto: saberemos em todos os pontos que os valores da negociação são sempre
os mesmos, não corremos o risco de um método que constrói o candlestick mexer nos nossos atributos
(deixando ou não num estado inconsistente), além de a imutabilidade também garantir que não haverá problemas no caso de acesso concorrente ao objeto.

2.8

Trabalhando com datas: Date e Calendar

Se você fez o FJ-21 conosco, já teve que lidar com as conversões entre Date e Calendar para pegar a entrada
de data de um texto digitado pelo usuário e convertê-lo para um objeto que representa datas em Java.
A classe mais antiga que representa uma data dentro do Java é a Date. Ela armazena a data de forma cada
momento do tempo seja representado por um número - isso quer dizer, que o Date guarda todas as datas
como milissegundos que se passaram desde 01/01/1970.
O armazenamento dessa forma não é de todo ruim, mas o problema é que a API não traz métodos que
ajudem muito a lidar com situações do dia como, por exemplo, adicionar dias ou meses a uma data.
A classe Date não mais é recomendada porque a maior parte de seus métodos estão marcados como
deprecated, porém ela tem amplo uso legado nas bibliotecas do java. Ela foi substituída no Java 1.1 pelo
Calendar, para haver suporte correto à internacionalização e à localização do sistema de datas.

Calendar: evolução do Date
A classe abstrata Calendar também encapsula um instante em milissegundos, como a Date, mas ela provê
métodos para manipulação desse momento em termos mais cotidianos como dias, meses e anos. Por ser
abstrata, no entanto, não podemos criar objetos que são simplesmente Calendars.
A subclasse concreta de Calendar mais usada é a GregorianCalendar, que representa o calendário usado pela
maior parte dos países -- outras implementações existem, como a do calendário budista BuddhistCalendar,
mas estas são bem menos usadas e devolvidas de acordo com seu Locale.
Para obter um Calendar que encapsula o instante atual (data e hora), usamos o método estático
getInstance() de Calendar.
Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Trabalhando com datas: Date e Calendar - Página 12


Calendar agora = Calendar.getInstance();

Porque não damos new diretamente em GregorianCalendar? A API do Java fornece esse método estático
que fabrica um objeto Calendar de acordo com uma série de regras que estão encapsuladas dentro de
getInstance. Esse é o padrão de projeto factory, que utilizamos quando queremos esconder a maneira em
que um objeto é instanciado. Dessa maneira podemos trocar implementações devolvidas como retorno a
medida que nossas necessidades mudem.
Nesse caso algum país que use calendários diferente do gregoriano pode implementar esse método de maneira adequada, retornando o que for necessário de acordo com o Locale configurado na máquina.

Effective Java
Item 1: Considere utilizar Factory com métodos estáticos em vez de construtores
Repare ainda que há uma sobrecarga desse método que recebe Locale ou Timezone como argumento, caso
você queira que essa factory trabalhe com valores diferentes dos valores que a JVM descobrir em relação ao
seu ambiente.
Um outro excelente exemplo de factory é o DriverManager do java.sql que fabrica Connection de acordo
com os argumentos passados.
A partir de um Calendar, podemos saber o valor de seus campos, como ano, mês, dia, hora, minuto, etc.
Para isso, usamos o método get que recebe um inteiro representando o campo; os valores possíveis estão em
constantes na classe Calendar.
No exemplo abaixo, imprimimos o dia de hoje e o dia da semana correspondente. Note que o dia da semana
devolvido é um inteiro que representa o dia da semana (Calendar.MONDAY etc):
Calendar c = Calendar.getInstance();
System.out.println("Dia do Mês: " + c.get(Calendar.DAY_OF_MONTH));
System.out.println("Dia da Semana: " + c.get(Calendar.DAY_OF_WEEK));

Um possível resultado é:
Dia do Mês: 4
Dia da Semana: 5

No exemplo acima, o dia da semana 5 representa a quinta-feira.
Da mesma forma que podemos pegar os valores dos campos, podemos atribuir novos valores a esses campos
por meio dos métodos set.
Há diversos métodos set em Calendar. O mais geral é o que recebe dois argumentos: o primeiro indica qual
é o campo (usando aquelas constantes de Calendar) e, o segundo, o novo valor. Além desse método, outros


métodos set recebem valores de determinados campos; o set de três argumentos, por exemplo, recebe ano,
mês e dia. Vejamos um exemplo de como alterar a data de hoje:
c.set(2011, Calendar.DECEMBER, 25, 10, 30);
// mudamos a data para as 10:30am do Natal

Outro método bastante usado é add, que adiciona uma certa quantidade a qualquer campo do Calendar. Por
exemplo, para uma aplicação de agenda, queremos adicionar um ano à data de hoje:
c.add(Calendar.YEAR, 1); // adiciona 1 ao ano

Note que, embora o método se chame add, você pode usá-lo para subtrair valores também; basta colocar
uma quantidade negativa no segundo argumento.
Os métodos after e before são usados para comparar o objeto Calendar em questão a outro Calendar. O
método after devolverá true quando o objeto atual do Calendar representar um momento posterior ao do
Calendar passado como argumento. Por exemplo, after devolverá false se compararmos o dia das crianças
com o Natal, pois o dia das crianças não vem depois do Natal:
Calendar c1 = new GregorianCalendar(2005, Calendar.OCTOBER, 12);
Calendar c2 = new GregorianCalendar(2005, Calendar.DECEMBER, 25);
System.out.println(c1.after(c2));

Analogamente, o método before verifica se o momento em questão vem antes do momento do Calendar
que foi passado como argumento. No exemplo acima, c1.before(c2) devolverá true, pois o dia das crianças
vem antes do Natal.
Note que Calendar implementa Comparable. Isso quer dizer que você pode usar o método compareTo para
comparar dois calendários. No fundo, after e before usam o compareTo para dar suas respostas - apenas,
fazem tal comparação de uma forma mais elegante e encapsulada.
Por último, um dos problemas mais comuns quando lidamos com datas é verificar o intervalo de dias entre
duas datas que podem ser até de anos diferentes. O método abaixo devolve o número de dias entre dois
objetos Calendar. O cálculo é feito pegando a diferença entre as datas em milissegundos e dividindo esse
valor pelo número de milissegundos em um dia:
public int diferencaEmDias(Calendar c1, Calendar c2) {
long m1 = c1.getTimeInMillis();
long m2 = c2.getTimeInMillis();
return (int) ((m2 - m1) / (24*60*60*1000));
}



Relacionando Date e Calendar
Você pode pegar um Date de um Calendar e vice-versa através dos métodos getTime e setTime presentes na
classe Calendar:
Calendar c = new GregorianCalendar(2005, Calendar.OCTOBER, 12);
Date d = c.getTime();
c.setTime(d);

Isso faz com que você possa operar com datas da maneira nova, mesmo que as APIs ainda usem objetos do
tipo Date (como é o caso de java.sql).

Para saber mais: Classes Deprecated e o JodaTime
O que fazer quando descobrimos que algum método ou alguma classe não saiu bem do jeito que deveria?
Simplesmente apagá-la e criar uma nova?
Essa é uma alternativa possível quando apenas o seu programa usa tal classe, mas definitivamente não é uma
boa alternativa se sua classe já foi usada por milhões de pessoas no mundo todo.
É o caso das classes do Java. Algumas delas (Date, por exemplo) são repensadas anos depois de serem lançadas e soluções melhores aparecem (Calendar). Mas, para não quebrar compatibilidade com códigos existentes, o Java mantém as funcionalidades problemáticas ainda na plataforma, mesmo que uma solução melhor
exista.
Mas como desencorajar códigos novos a usarem funcionalidades antigas e não mais recomendadas? A prática
no Java para isso é marcá-las como deprecated. Isso indica aos programadores que não devemos mais usá-las
e que futuramente, em uma versão mais nova do Java, podem sair da API (embora isso nunca tenha ocorrido
na prática).
Antes do Java 5, para falar que algo era deprecated, usava-se um comentário especial no Javadoc. A partir
do Java 5, a anotação @Deprecated foi adicionada à plataforma e garante verificações do próprio compilador
(que gera um warning). Olhe o Javadoc da classe Date para ver tudo que foi deprecated.
A API de datas do Java, mesmo considerando algumas melhorias da Calendar em relação a Date, ainda é
muito pobre. Numa próxima versão novas classes para facilitar ainda mais o trabalho com datas e horários
devem entrar na especificação do Java, baseadas na excelente biblioteca JodaTime.
Para mais informações: http://blog.caelum.com.br/2007/03/15/jsr-310-date-and-time-api/ http://jcp.org/en/
jsr/detail?id=310

2.9

Exercícios: o modelo do Argentum

1) Vamos criar o projeto fj22-argentum no Eclipse, já com o foco em usar a IDE melhor: use o atalho ctrl
+ N, que cria novo... e comece a digitar Java Project:
Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Exercícios: o modelo do Argentum - Página 15


2) Na janela que abrirá em sequência, preencha o nome do projeto como fj22-argentum e clique em Next:

3) Na próxima tela, podemos definir uma série de configurações do projeto (que também podem ser feitas
depois, através do menu Build path -> Configure build path, clicando com o botão da direita no projeto.
Queremos mudar o diretório que conterá nosso código fonte. Faremos isso para organizar melhor nosso
projeto e utilizar convenções amplamente utilizadas no mercado.
Nessa tela, remova o diretório src da lista de diretórios fonte:



Agora, na mesma tela, adicione um novo diretório fonte, chamado src/main/java. Para isso, clique em
Create new source folder e preencha com src/main/java:

4) Agora basta clicar em Finish. A estrutura final de seu projeto deve estar parecida com isso:



5) Crie

a

classe

usando

ctrl + N
br.com.caelum.argentum.modelo:

Class,

chamada

Negociacao

e

dentro

do

pacote

6) Transforme a classe em final e já declare os três atributos que fazem parte de uma negociação da bolsa de
valores (também como final):
public final class Negociacao {
private final double preco;
private final int quantidade;
private final Calendar data;
}



Não esqueça de importar o Calendar!
7) Vamos criar um construtor que recebe esses dados, já que são obrigatórios para nosso domínio. Em vez
de fazer isso na mão, na edição da classe, use o atalho ctrl + 3 e comece a digitar constructor. Ele vai
mostrar uma lista das opções que contêm essa palavra: escolha a Generate constructor using fields.
Alternativamente, tecle ctrl + 3 e digite GCUF, que são as iniciais do menu que queremos acessar.

Agora, selecione todos os campos e marque para omitir a invocação ao super, como na tela abaixo.
Atenção para deixar os campos na ordem ‘preco, quantidade, data’. Você pode usar os botões Up e
Down para mudar a ordem.

Pronto! Mande gerar. O seguinte código que será gerado:
public Negociacao(double preco, int quantidade, Calendar data) {
this.preco = preco;
this.quantidade = quantidade;
this.data = data;
}



8) Agora, vamos gerar os getters dessa classe. Faça ctrl + 3 e comece a digitar getter, as opções aparecerão e
basta você escolher generate getters and setters. É sempre bom praticar os atalhos do ctrl + 3.

Selecione os getters e depois Finish:

9) Verifique sua classe. Ela deve estar assim:
public final class Negociacao {
private final double preco;
private final int quantidade;
this.preco = preco;
this.data = data;
}
public double getPreco() {
return preco;
}
public int getQuantidade() {
return quantidade;
}
public Calendar getData() {


return data;
}
}

10) Um dado importante para termos noção da estabilidade de uma ação na bolsa de valores é o volume de
dinheiro negociado em um período.
Vamos fazer nossa classe Negociacao devolver o volume de dinheiro transferido naquela negociação.
Na prática, é só multiplicar o preco pago pela quantidade de ações negociadas, resultando no total de
dinheiro que aquela negociação realizou.
Adicione o método getVolume na classe Negociacao:
public double getVolume() {
return preco * quantidade;
}

Repare que um método que parece ser um simples getter pode (e deve muitas vezes) encapsular regras de
negócio e não necessariamente refletem um atributo da classe.
11) Siga o mesmo procedimento para criar a classe Candlestick. Use o ctrl + N Class para isso, marque-a
como final e adicione os seguintes atributos finais, nessa ordem:
public final class Candlestick {
private final double abertura;
private final double fechamento;
private final double minimo;
private final double maximo;
private final double volume;
}

12) Use o ctrl + 3 para gerar o construtor com os seis atributos. Atenção à ordem dos parâmetros no construtor:



13) Gere também os seis respectivos getters, usando o ctrl + 3.
A classe final deve ficar parecida com a que segue:
public final class Candlestick {
private final double abertura;
private final double fechamento;
private final double minimo;
private final double maximo;
private final double volume;
public Candlestick(double abertura,double fechamento,double minimo,
double maximo, double volume, Calendar data) {
this.abertura = abertura;
this.fechamento = fechamento;
this.minimo = minimo;
this.maximo = maximo;
this.volume = volume;
this.data = data;
}
public double getAbertura() {
return abertura;
}
public double getFechamento() {
return fechamento;
}
public double getMinimo() {


return minimo;
}
public double getMaximo() {
return maximo;
}
public double getVolume() {
return volume;
}
return data;
}
}

14) (opcional) Vamos adicionar dois métodos de negócio, para que o Candlestick possa nos dizer se ele é do
tipo de alta, ou se é de baixa:
public boolean isAlta() {
return this.abertura < this.fechamento;
}
public boolean isBaixa() {
return this.abertura > this.fechamento;
}

2.10

Resumo diário das Negociações

Agora que temos as classes que representam negociações na bolsa de valores (Negociacao) e resumos diários
dessas negociações (Candlestick), falta apenas fazer a ação de resumir as negociações de um dia em uma
candle.
A regra é um tanto simples: dentre uma lista de negociações, precisamos descobrir quais são os valores a
preencher na Candlestick:
• Abertura: preço da primeira negociação do dia;
• Fechamento: preço da última negociação do dia;
• Mínimo: preço da negociação mais barata do dia;
• Máximo: preço da negociação mais cara do dia;
• Volume: quantidade de dinheiro que passou em todas as negociações nesse dia;
• Data: a qual dia o resumo se refere.
Algumas dessas informações são fáceis de encontrar por que temos uma convenção no sistema: quando vamos criar a candle, a lista de negociações já vem ordenada por tempo. Dessa forma, a abertura e o fechamento
Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Resumo diário das Negociações - Página 23


são triviais: basta recuperar o preço , respectivamente, da primeira e da última negociações do dia!
Já mínimo, máximo e volume precisam que todos os valores sejam verificados. Dessa forma, precisamos
passar por cada negociação da lista verificando se aquele valor é menor do que todos os outros que já vimos, maior que nosso máximo atual. Aproveitando esse processo de passar por cada negociação, já vamos
somando o volume de cada negociação.
O algoritmo, agora, está completamente especificado! Basta passarmos essas ideias para código. Para isso,
lembremos, você pode usar alguns atalhos que já vimos antes:
• Ctrl + N: cria novo(a)...
• Ctrl + espaço: autocompleta
• Ctrl + 1: resolve pequenos problemas de compilação e atribui objetos a variáveis.

Em que classe colocar?
Falta apenas, antes de pôr em prática o que aprendemos, decidirmos onde vai esse código de criação de
Candlestick. Pense bem a respeito disso: será que uma negociação deveria saber resumir vários de si em
uma candle? Ou será que uma Candlestick deveria saber gerar um objeto do próprio tipo Candlestick a
partir de uma lista de negociações.
Em ambos os cenários, nossos modelos têm que ter informações a mais que, na realidade, são responsabilidades que não cabem a eles!
Criaremos, então, uma classe que: dado a matéria-prima, nos constrói uma candle. E uma classe com esse
comportamento, que recebem o necessário para criar um objeto e encapsulam o algoritmo para tal criação,
costuma ser chamadas de Factory.
No nosso caso particular, essa é uma fábrica que cria Candlesticks, então, seu nome fica
CandlestickFactory.
Perceba que esse nome, apesar de ser um tal Design Pattern nada mais faz do que encapsular uma lógica um
pouco mais complexa, isto é, apenas aplica boas práticas de orientação a objetos que você já vem estudando
desde o FJ-11.

2.11

Exercícios: fábrica de Candlestick

1) Como o resumo de Negociacoes em um Candlestick é um processo complicado, vamos encapsular sua
construção através de uma fábrica, assim como vimos a classe Calendar, porém o método de fabricação
ficará numa classe a parte, o que também é muito comum. Vamos criar a classe CandlestickFactory
dentro do pacote br.com.caelum.argentum.modelo:

Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Exercícios: fábrica de Candlestick - Página 24


Depois de criá-la, adicione a assinatura do método constroiCandleParaData como abaixo:
public class CandlestickFactory {
// ctrl + 1 para adicionar o return automaticamente
public Candlestick constroiCandleParaData(Calendar data,
List<Negociacao> negociacoes) {
}
}

2) Calcularemos o preço máximo e mínimo percorrendo todas as negociações e achando os valores corretos. Para isso, usaremos variáveis temporárias e, dentro do for, verificaremos se o preço da negociação
atual bate ou máximo. Se não bater, veremos se ele é menor que o mínimo. Calculamos o volume somando o volume de cada negociação em uma variável. Podemos pegar o preço de abertura através de
negociacoes.get(0) e o de fechamento por negociacoes.get(negociacoes.size() - 1).
public class CandlestickFactory {
public Candlestick constroiCandleParaData(Calendar data,
List<Negociacao> negociacoes) {
double maximo = negociacoes.get(0).getPreco();
double minimo = negociacoes.get(0).getPreco();
double volume = 0;



// digite foreach e dê um ctrl + espaço para ajudar a
// criar o bloco abaixo!
for (Negociacao negociacao : negociacoes) {
volume += negociacao.getVolume();
if (negociacao.getPreco() > maximo) {
maximo = negociacao.getPreco();
} else if (negociacao.getPreco() < minimo) {
minimo = negociacao.getPreco();
}
}
double abertura = negociacoes.get(0).getPreco();
double fechamento = negociacoes.get(negociacoes.size()-1).getPreco();
return new Candlestick(abertura, fechamento, minimo, maximo,
volume, data);
}
}

3) Vamos testar nosso código, criando 4 negociações e calculando o Candlestick, finalmente. Crie a classe
TestaCandlestickFactory no pacote br.com.caelum.argentum.testes
public class TestaCandlestickFactory {
public static void main(String[] args) {
Calendar hoje = Calendar.getInstance();
Negociacao
Negociacao
Negociacao
Negociacao

negociacao1
negociacao2
negociacao3
negociacao4

=
=
=
=

new
new
new
new

Negociacao(40.5,
Negociacao(45.0,
Negociacao(39.8,
Negociacao(42.3,

100,
100,
100,
100,

hoje);
hoje);
hoje);
hoje);

List<Negociacao> negociacoes = Arrays.asList(negociacao1, negociacao2,
negociacao3, negociacao4);
CandlestickFactory fabrica = new CandlestickFactory();
Candlestick candle = fabrica.constroiCandleParaData(
hoje, negociacoes);
System.out.println(candle.getAbertura());
System.out.println(candle.getFechamento());
System.out.println(candle.getMinimo());
System.out.println(candle.getMaximo());
System.out.println(candle.getVolume());


}
}

O método asList da classe java.util.Arrays cria uma lista dada uma array. Mas não passamos
nenhuma array como argumento! Isso acontece porque esse método aceita varargs, possibilitando que
invoquemos esse método separando a array por vírgula. Algo parecido com um autoboxing de arrays.

Effective Java
Item 47: Conheça e use as bibliotecas!
A saída deve ser parecida com:
40.5
42.3
39.8
45.0
16760.0

2.12

Exercícios opcionais
Effective Java

1)
Item 10: Sempre reescreva o toString
Reescreva o toString da classe Candlestick. Como o toString da classe Calendar retorna uma
String bastante complexa, faça com que a data seja corretamente visualizada, usando para isso o
SimpleDateFormat. Procure sobre essa classe na API do Java.
Ao imprimir um candlestick, por exemplo, a saída deve ser algo como segue:
[Abertura 40.5, Fechamento 42.3, Mínima 39.8, Máxima 45.0,
Volume 145234.20, Data 12/07/2008]

Para reescrever um método e tirar proveito do Eclipse, a maneira mais direta é de dentro da classe
Candlestick, fora de qualquer método, pressionar ctrl + espaço.
Uma lista com todas as opções de métodos que você pode reescrever vai aparecer. Escolha o toString, e
ao pressionar enter o esqueleto da reescrita será montado.
2) Um double segue uma regra bem definida em relação a contas e arredondamento, e para ser rápido e caber
em 64 bits, não tem precisão infinita. A classe BigDecimal pode oferecer recursos mais interessantes em
um ambiente onde as casas decimais são valiosas, como um sistema financeiro. Pesquise a respeito.
Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Exercícios opcionais - Página 27


3) O construtor da classe Candlestick é simplesmente muito grande. Poderíamos usar uma factory, porém
continuaríamos passando muitos argumentos para um determinado método.
Quando construir um objeto é complicado, ou confuso, costumamos usar o padrão Builder para resolver
isso. Builder é uma classe que ajudar você a construir um determinado objeto em uma série de passos,
independente de ordem.

Effective Java
Item 2: Considere usar um builder se o construtor tiver muitos parâmetros!
A ideia é que possamos criar um candle da seguinte maneira:
CandleBuilder builder = new CandleBuilder();
builder.comAbertura(40.5);
builder.comFechamento(42.3);
builder.comMinimo(39.8);
builder.comMaximo(45.0);
builder.comVolume(145234.20);
builder.comData(new GregorianCalendar(2012, 8, 12, 0, 0, 0));
Candlestick candle = builder.geraCandle();

Os setters aqui possuem nomes mais curtos e expressivos. Mais ainda: utilizando o padrão de projeto
fluent interface, podemos tornar o código acima mais conciso, sem perder a legibilidade:
Candlestick candle = new CandleBuilder().comAbertura(40.5)
.comFechamento(42.3).comMinimo(39.8).comMaximo(45.0)
.comVolume(145234.20).comData(
new GregorianCalendar(2008, 8, 12, 0, 0, 0)).geraCandle();

Para isso, a classe CandleBuilder deve usar o seguinte idiomismo:
public class CandleBuilder {
private double abertura;
// outros 5 atributos
public CandleBuilder comAbertura(double abertura) {
this.abertura = abertura;
return this;
}
// outros 5 setters que retornam this


public Candlestick geraCandle() {
return new Candlestick(abertura, fechamento, minimo, maximo,
volume, data);
}
}

Escreva um código com main que teste essa sua nova classe. Repare como o builder parece bastante com
a StringBuilder, que é uma classe builder que ajuda a construir Strings através de fluent interface e
métodos auxiliares.

Usos famosos de Fluent Interface e DSLs
Fluent interfaces são muito usadas no Hibernate, por exemplo. O jQuery, uma famosa biblioteca
de efeitos javascript, popularizou-se por causa de sua fluent interface. O JodaTime e o JMock são
dois excelentes exemplos.
São muito usadas (e recomendadas) na construção de DSLs, Domain Specific Languages. Martin
Fowler fala bastante sobre fluent interfaces nesse ótimo artigo:
http://martinfowler.com/bliki/FluentInterface.html


Capítulo 3

Testes Automatizados
“Apenas duas coisas são infinitas: o universo e a estupidez humana. E eu não tenho certeza do primeiro.”
– Albert Einstein

3.1

Nosso código está funcionando corretamente?

Escrevemos uma quantidade razoável de código no capítulo anterior, meia dúzia de classes. Elas funcionam
corretamente? Tudo indica que sim, até criamos um pequeno main para verificar isso e fazer as perguntas
corretas.
Pode parecer que o código funciona, mas ele tem muitas falhas. Olhemos com mais cuidado.

3.2

Exercícios: testando nosso modelo sem frameworks

1) Será que nosso programa funciona para um determinado dia que ocorrer apenas uma única negociação?
Vamos escrever o teste, e ver o que acontece:
public class TestaCandlestickFactoryComUmaNegociacaoApenas {
Negociacao negociacao1 = new Negociacao(40.5, 100, hoje);
List<Negociacao> negociacoes = Arrays.asList(negociacao1);


Candlestick candle = fabrica.constroiCandleParaData(hoje, negociacoes);
}
}

A saída deve indicar 40.5 como todos os valores, e 4050.0 como volume. Tudo parece bem?
2) Mais um teste: as ações menos negociadas podem ficar dias sem nenhuma operação acontecer. O que
nosso sistema gera nesse caso?
Vamos ao teste:
public class TestaCandlestickFactorySemNegociacoes {
List<Negociacao> negociacoes = Arrays.asList();
}
}

Rodando o que acontece? Você acha essa saída satisfatória? Indica bem o problema?

3) ArrayIndexOutOfBoundsException certamente é uma péssima exceção para indicar que não teremos
Candle.

Capítulo 3 - Testes Automatizados - Exercícios: testando nosso modelo sem frameworks - Página 31


Qual decisão vamos tomar? Podemos lançar nossa própria exception, podemos retornar null ou ainda
podemos devolver um Candlestick que possui um significado especial. Devolver null deve ser sempre
a última opção.
Vamos retornar um Candlestick que possui um volume zero. Para corrigir o erro, vamos alterar o código
do nosso CandlestickFactory.
Poderíamos usar um if logo de cara para verificar se negociacoes.isEmpty(), porém podemos tentar
algo mais sutil, sem ter que criar vários pontos de return.
Vamos então iniciar os valores de minimo e maximo sem usar a lista, que pode estar vazia. Mas, para
nosso algoritmo funcionar, precisaríamos iniciar o minimo com um valor bem grande, assim quando
percorrermos o for qualquer valor já vai ser logo minimo. Mesmo com maximo, que deve ter um valor
bem pequeno.
Mas quais valores colocar? Quanto é um número pequeno o suficiente? Ou um número grande o suficiente? Na classe Double, encontramos constantes que representam os maiores e menores números existentes.
Altere o método constroiCandleParaData da classe CandlestickFactory:
double maximo = Double.MIN_VALUE;
double minimo = Double.MAX_VALUE;

Além disso, devemos verificar se negociacoes está vazia na hora de calcular o preço de abertura e
fechamento. Altere novamente o método:
double abertura = negociacoes.isEmpty() ? 0 : negociacoes.get(0).getPreco();
double fechamento = negociacoes.isEmpty() ? 0 :
negociacoes.get(negociacoes.size() - 1).getPreco();

Pronto! Rode o teste, deve vir tudo zero e números estranhos para máximo e mínimo!
4) Será que tudo está bem? Rode novamente os outros dois testes, o que acontece?
Incrível! Consertamos um bug, mas adicionamos outro. A situação lhe parece familiar? Nós desenvolvedores vivemos com isso o tempo todo: tentando fugir dos velhos bugs que continuam a reaparecer!
O teste com apenas uma negociação retorna 1.7976931348623157E308 como valor mínimo agora! Mas
deveria ser 40.5. Ainda bem que lembramos de rodar essa classe, e que percebemos que esse número está
diferente do que deveria ser.
Vamos sempre confiar em nossa memória?
5) (opcional) Será que esse erro está ligado a ter apenas uma negociação? Vamos tentar com mais negociações? Crie e rode um teste com as seguintes negociações:

Capítulo 3 - Testes Automatizados - Exercícios: testando nosso modelo sem frameworks - Página 32



E com uma sequência decrescente, funciona? Por quê?

3.3

Definindo melhor o sistema e descobrindo mais bugs

Segue uma lista de dúvidas pertinentes ao Argentum. Algumas dessas perguntas você não saberá responder, porque não definimos muito bem o comportamento de alguns métodos e classes. Outras você saberá
responder.
De qualquer maneira, crie um código curto para testar cada uma das situações, em um main apropriado.
1) Uma negociação da Petrobras a 30 reais, com uma quantidade negativa de negociações é válida? E com
número zero de negociações?
Em outras palavras, posso dar new em uma Negociacao com esses dados?
2) Uma negociação com data nula é válida? Posso dar new Negociacao(10, 5, null)? Deveria poder?
3) Um candle é realmente imutável? Não podemos mudar a data de um candle de maneira alguma?
4) Um candle em que o preço de abertura é igual ao preço de fechamento, é um candle de alta ou de baixa?
O que o sistema diz? O que o sistema deveria dizer?
5) Como geramos um candle de um dia que não houve negociação? O que acontece?
6) E se a ordem das negociações passadas ao CandlestickFactory não estiver na ordem crescente das datas?
Devemos aceitar? Não devemos?
7) E se essas Negociações forem de dias diferentes que a data passada como argumento para a factory?

3.4

Testes de Unidade

Testes de unidade são testes que testam apenas uma classe ou método, verificando se seu comportamento
está de acordo com o desejado. Em testes de unidade, verificamos a funcionalidade da classe e/ou método
em questão passando o mínimo possível por outras classes ou dependências do nosso sistema.

Unidade
Unidade é a menor parte testável de uma aplicação. Em uma linguagem de programação orientada a objetos como o Java, a menor unidade é um método.
O termo correto para esses testes é testes de unidade, porém o termo teste unitário propagou-se
e é o mais encontrado nas traduções.
Capítulo 3 - Testes Automatizados - Definindo melhor o sistema e descobrindo mais bugs - Página 33


Em testes de unidade, não estamos interessados no comportamento real das dependências da classe, mas em
como a classe em questão se comporta diante das possíveis respostas das dependências, ou então se a classe
modificou as dependências da maneira esperada.
Para isso, quando criamos um teste de unidade, simulamos a execução de métodos da classe a ser testada.
Fazemos isso passando parâmetros (no caso de ser necessário) ao método testado e definimos o resultado
que esperamos. Se o resultado for igual ao que definimos como esperado, o teste passa. Caso contrário, falha.

Atenção
Muitas vezes, principalmente quando estamos iniciando no mundo dos testes, é comum criarmos
alguns testes que testam muito mais do que o necessário, mais do que apenas a unidade. Tais
testes se transformam em verdadeiros testes de integração (esses sim são responsáveis por testar
o sistemas como um todo).
Portanto, lembre-se sempre: testes de unidade testam apenas unidades!

3.5

JUnit

O JUnit (junit.org) é um framework muito simples para facilitar a criação destes testes de unidade e em
especial sua execução. Ele possui alguns métodos que tornam seu código de teste bem legível e fácil de fazer
as asserções.
Uma asserção é uma afirmação: alguma invariante que em determinado ponto de execução você quer garantir que é verdadeira. Se aquilo não for verdade, o teste deve indicar uma falha, a ser reportada para o
programador, indicando um possível bug.
À medida que você mexe no seu código, você roda novamente toda aquela bateria de testes com um comando
apenas. Com isso você ganha a confiança de que novos bugs não estão sendo introduzidos (ou reintroduzidos) conforme você cria novas funcionalidades e conserta antigos bugs. Mais fácil do que ocorre quando
fazemos os testes dentro do main, executando um por vez.
O JUnit possui integração com todas as grandes IDEs, além das ferramentas de build, que vamos conhecer
mais a frente. Vamos agora entender um pouco mais sobre anotações e o import estático, que vão facilitar
muito o nosso trabalho com o JUnit.

Usando o JUnit - configurando Classpath e seu JAR no Eclipse
O JUnit é uma biblioteca escrita por terceiros que vamos usar no nosso projeto. Precisamos das classes do
JUnit para escrever nossos testes. E, como sabemos, o formato de distribuição de bibliotecas Java é o JAR,
muito similar a um ZIP com as classes daquela biblioteca.
Precisamos então do JAR do JUnit no nosso projeto. Mas quando rodarmos nossa aplicação, como o Java vai
saber que deve incluir as classes daquele determinado JAR junto com nosso programa? (dependência)
Capítulo 3 - Testes Automatizados - JUnit - Página 34


É aqui que o Classpath entra história: é nele que definimos qual o “caminho para buscar as classes que vamos
usar”. Temos que indicar onde a JVM deve buscar as classes para compilar e rodar nossa aplicação.
Há algumas formas de configurarmos o classpath:
• Configurando uma variável de ambiente (desaconselhado);
• Passando como argumento em linha de comando (trabalhoso);
• Utilizando ferramentas como Ant e Maven (veremos mais a frente);
• Deixando o eclipse configurar por você.
No Eclipse, é muito simples:
1) Clique com o botão direito em cima do nome do seu projeto.
2) Escolha a opção Properties.
3) Na parte esquerda da tela, selecione a opção “Java Build Path”.
E, nessa tela:
1) “Java Build Path” é onde você configura o classpath do seu projeto: lista de locais definidos que, por
padrão, só vêm com a máquina virtual configurada;
2) Opções para adicionar mais caminhos, “Add JARs...” adiciona Jar’s que estejam no seu projeto; “Add
External JARs” adiciona Jar’s que estejam em qualquer outro lugar da máquina, porém guardará uma
referência para aquele caminho (então seu projeto poderá não funcionar corretamente quando colocado
em outro micro, mas existe como utilizar variáveis para isso);
No caso do JUnit, por existir integração direta com Eclipse, o processo é ainda mais fácil, como veremos no
exercício. Mas para todas as outras bibliotecas que formos usar, basta copiar o JAR e adicioná-lo ao Build
Path. Vamos ver esse procedimento com detalhes quando usarmos as bibliotecas que trabalham com XML
e gráficos em capítulos posteriores.

3.6

Anotações

Anotação é a maneira de escrever metadados na própria classe, isto é, configurações ou outras informações
pertinentes a essa classe. Esse recurso foi introduzido no Java 5.0. Algumas anotações podem ser mantidas
(retained) no .class, permitindo que possamos reaver essas informações, se necessário.
É utilizada, por exemplo, para indicar que determinada classe deve ser processada por um framework de
uma certa maneira, evitando assim as clássicas configurações através de centenas de linhas de XML.
Apesar dessa propriedade interessante, algumas anotações servem apenas para indicar algo ao compilador.
@Override é o exemplo disso. Caso você use essa anotação em um método que não foi reescrito, vai haver
um erro de compilação! A vantagem de usá-la é apenas para facilitar a legibilidade.
Capítulo 3 - Testes Automatizados - Anotações - Página 35


@Deprecated indica que um método não deve ser mais utilizado por algum motivo e decidiram não retirá-lo

da API para não quebrar programas que já funcionavam anteriormente.
@SurpressWarnings indica para o compilador que ele não deve dar warnings a respeito de determinado

problema, indicando que o programador sabe o que está fazendo. Um exemplo é o warning que o compilador
do Eclipse dá quando você não usa determinada variável. Você vai ver que um dos quick fixes é a sugestão
de usar o @SupressWarnings.
Anotações podem receber parâmetros. Existem muitas delas na API do java 5, mas realmente é ainda mais
utilizada em frameworks, como o Hibernate 3, o EJB 3 e o JUnit4.

3.7

JUnit4, convenções e anotação

Para cada classe, teremos uma classe correspondente (por convenção, com o sufixo Test) que contará todos
os testes relativos aos métodos dessa classe. Essa classe ficará no pacote de mesmo nome, mas na Source
Folder de testes (src/test/java).
Por exemplo, para a nossa CandlestickFactory, teremos a CandlestickFactoryTest:
package br.com.caelum.argentum.modelo;
public class CandlestickFactoryTest {
public void sequenciaSimplesDeNegociacoes() {
Negociacao
Negociacao
Negociacao
Negociacao

negociacao1
negociacao2
negociacao3
negociacao4

=
=
=
=

new
new
new
new

Negociacao(40.5,
Negociacao(45.0,
Negociacao(39.8,
Negociacao(42.3,

100,
100,
100,
100,

hoje);
hoje);
hoje);
hoje);

}
}

Em vez de um main, criamos um método com nome expressivo para descrever a situação que ele está testando.
Mas... como o JUnit saberá que deve executar aquele método? Para isso anotamos este método com @Test,
que fará com que o JUnit saiba no momento de execução, por reflection, de que aquele método deva ser
executado:

Capítulo 3 - Testes Automatizados - JUnit4, convenções e anotação - Página 36


@Test
// ...
}
}

Pronto! Quando rodarmos essa classe como sendo um teste do JUnit, esse método será executado e a View
do JUnit no Eclipse mostrará se tudo ocorreu bem. Tudo ocorre bem quando o método é executado sem
lançar exceções inesperadas e se todas as asserções passarem.
Uma asserção é uma verificação. Ela é realizada através dos métodos estáticos da classe Assert, importada
do org.junit. Por exemplo, podemos verificar se o valor de abertura desse candle é 40.5:
Assert.assertEquals(40.5, candle.getAbertura(), 0.00001);

O primeiro argumento é o que chamamos de expected, e ele representa o valor que esperamos para argumento
seguinte (chamado de actual). Se o valor real for diferente do esperado, o teste não passará e uma barrinha
vermelha será mostrada, juntamente com uma mensagem que diz:
expected <valor esperado> but was <o que realmente deu>

Double é inexato
Logo na primeira discussão desse curso, conversamos sobre a inexatidão do double ao trabalhar com arredondamentos. Porém, diversas vezes, gostaríamos de comparar o double esperado e o valor real, sem nos
preocupar com diferenças de arredondamento quando elas são muito pequenas.
O JUnit trata esse caso adicionando um terceiro argumento, que só é necessário quando comparamos valores
double ou float. Ele é um delta que se aceita para o erro de comparação entre o valor esperado e o real.
Por exemplo, quando lidamos com dinheiro, o que nos importa são as duas primeiras casas decimais e,
portanto, não há problemas se o erro for na quinta casa decimal. Em softwares de engenharia, no entanto,
um erro na quarta casa decimal pode ser um grande problema e, portanto, o delta deve ser ainda menor.
Nosso código final do teste, agora com as devidas asserções, ficará assim:
@Test
Capítulo 3 - Testes Automatizados - JUnit4, convenções e anotação - Página 37


Assert.assertEquals(42.3, candle.getFechamento(), 0.00001);
Assert.assertEquals(39.8, candle.getMinimo(), 0.00001);
Assert.assertEquals(45.0, candle.getMaximo(), 0.00001);
Assert.assertEquals(1676.0, candle.getVolume(), 0.00001);
}
}

Existem ainda outras anotações principais e métodos importantes da classe Assert, que conheceremos no
decorrer da construção do projeto.

3.8

Exercícios: migrando os testes do main para JUnit

1) É considerada boa prática separar as classes de testes das classes principais. Para isso, normalmente se
cria um novo source folder apenas para os testes. Vamos fazer isso:
a) Ctrl + N e comece a digitar “Source Folder” até que o filtro a encontre:

b) Preencha com src/test/java e clique Finish:
Capítulo 3 - Testes Automatizados - Exercícios: migrando os testes do main para JUnit - Página 38


É nesse novo diretório em que você colocará todos seus testes de unidade.
2) Vamos criar um novo unit test em cima da classe CandlestickFactory. O Eclipse já ajuda bastante: com
o editor na CandlestickFactory, crie um novo (ctrl + N) JUnit Test Case.
Na janela seguinte, selecione o source folder como src/test/java. Não esqueça, também, de selecionar
JUnit4.



Ao clicar em Finish, o Eclipse te perguntará se pode adicionar os jars do JUnit no projeto.

A anotação @Test indica que aquele método deve ser executado na bateria de testes, e a classe Assert possui uma série de métodos estáticos que realizam comparações, e no caso de algum problema um exceção
é lançada.
Vamos colocar primeiro o teste inicial:
@Test
Negociacao
Negociacao
Negociacao
Negociacao

negociacao1
negociacao2
negociacao3
negociacao4

=
=
=
=

new
new
new
new

Negociacao(40.5,
Negociacao(45.0,
Negociacao(39.8,
Negociacao(42.3,

100,
100,
100,
100,

hoje);
hoje);
hoje);
hoje);

}
}

Para rodar, use qualquer um dos seguintes atalhos:
• ctrl + F11: roda o que estiver aberto no editor;



• alt + shift + X (solte) T: roda testes do JUnit.
Não se assuste! Houve a falha porque o número esperado do volume está errado no teste. Repare que
o Eclipse já associa a falha para a linha exata da asserção e explica porque falhou:

O número correto é mesmo 16760.0. Adicione esse zero na classe de teste e rode-o novamente:

É comum digitarmos errado no teste e o teste falhar, por isso, é importante sempre verificar a corretude
do teste, também!
3) Vamos adicionar outro método de teste à mesma classe CandlestickFactoryTest, dessa vez para testar
o método no caso de não haver nenhuma negociação:
@Test
public void semNegociacoesGeraCandleComZeros() {



List<Negociacao> negociacoes = Arrays.asList();
}

Rode o teste com o mesmo atalho.
4) E, agora, vamos para o que tem apenas uma negociação e estava falhando. Ainda na classe
CandlestickFactoryTest adicione o método: (repare que cada classe de teste possui vários métodos
com vários casos diferentes)
@Test
public void apenasUmaNegociacaoGeraCandleComValoresIguais() {
List<Negociacao> negociacoes = Arrays.asList(negociacao1);
}

Rode o teste. Repare no erro:



Como consertar?

3.9

Vale a pena testar classes de modelo?

Faz todo sentido testar classes como a CandlestickFactory, já que existe um algoritmo nela, alguma lógica
que deve ser executada e há uma grande chance de termos esquecido algum comportamento para casos
incomuns - como vimos nos testes anteriores.
Mas as classes de modelo, Negociacao e Candlestick, também precisam ser testadas?
A resposta para essa pergunta é um grande e sonoro sim! Apesar de serem classes mais simples elas também
têm comportamentos específicos como:
1) as classes Negociacao e Candlestick devem ser imutáveis, isto é, não devemos ser capazes de alterar
nenhuma de suas informações depois que o objeto é criado;
2) valores negativos também não deveriam estar presentes nas negociações e candles;
3) se você fez o opcional CandleBuilder, ele não deveria gerar a candle se os valores não tiverem sido preenchidos;
4) etc...
Por essa razão, ainda que sejam classes mais simples, elas merecem ter sua integridade testada - mesmo
porque são os objetos que representam nosso modelo de negócios, o coração do sistema que estamos desenvolvendo.
Capítulo 3 - Testes Automatizados - Vale a pena testar classes de modelo? - Página 43


3.10

Exercícios: novos testes

1) A classe Negociacao é realmente imutável?
Vamos criar um novo Unit Test para a classe Negociacao. O processo é o mesmo que fizemos para o teste
da CandlestickFactory: abra a classe Negociacao no editor e faça Ctrl + N JUnit Test Case.
Lembre-se de alterar a Source Folder para src/test/java e selecionar o JUnit 4.
public class NegociacaoTest {
@Test
public void dataDaNegociacaoEhImutavel() {
// se criar um negocio no dia 15...
c.set(Calendar.DAY_OF_MONTH, 15);
Negociacao n = new Negociacao(10, 5, c);

// ainda que eu tente mudar a data para 20...
n.getData().set(Calendar.DAY_OF_MONTH, 20);
// ele continua no dia 15.
Assert.assertEquals(15, n.getData().get(Calendar.DAY_OF_MONTH));
}
}

Você pode rodar esse teste apenas, usando o atalho (alt + shift + X T) ou pode fazer melhor e o que é mais
comum, rodar todos os testes de unidade de um projeto.
Basta selecionar o projeto na View Package Explorer e mandar rodar os testes: para essa ação, o único
atalho possível é o alt + shift + X T.

Capítulo 3 - Testes Automatizados - Exercícios: novos testes - Página 44


Esse teste falha porque devolvemos um objeto mutável através de um getter. Deveríamos ter retornado
uma cópia desse objeto para nos assegurarmos que o original permanece intacto.

Effective Java
Item 39: Faça cópias defensivas quando necessário.
Basta alterar a classe Negociacao e utilizar o método clone que todos os objetos têm (mas só quem
implementa Cloneable executará com êxito):
return (Calendar) this.data.clone();
}

Sem clone, precisaríamos fazer esse processo na mão. Com Calendar é relativamente fácil:
Calendar copia = Calendar.getInstance();
copia.setTimeInMillis(this.data.getTimeInMillis());
return copia;
}

Com outras classes, em especial as que tem vários objetos conectados, isso pode ser mais complicado.



Listas e arrays
Esse também é um problema que ocorre muito com coleções e arrays: se você retorna uma List
que é um atributo seu, qualquer um pode adicionar ou remover um elemento de lá, causando
estrago nos seus atributos internos.
Os métodos Collections.unmodifiableList(List) e outros ajudam bastante nesse trabalho.
2) Podemos criar uma Negociacao com data nula? Por enquanto, podemos, mas não deveríamos. Para que
outras partes do meu sistema não se surpreendam mais tarde, vamos impedir que a Negociacao seja criada
se sua data estiver nula, isto é, vamos lançar uma exceção.
Mas qual exceção? Vale a pena criar uma nova exceção para isso?
A exceção padrão no Java para cuidar de parâmetros indesejáveis é a IllegalArgumentException então,
em vez de criar uma nova com a mesma semântica, vamos usá-la para isso.

Effective Java
Item 60: Favoreça o uso das exceções padrões!
Antes de fazer a modificação na classe, vamos preparar o teste. Mas o que queremos testar? Queremos
saber se nossa classe Negociacao não permite a criação do objeto e lança uma IllegalArgumentException
quando passamos null no construtor.
Ou seja, esperamos que uma exceção aconteça! Para o teste passar, ele precisa dar a exceção (parece meio
contraditório). É fácil fazer isso com JUnit.
Adicione um novo método naoCriaNegociacaoComDataNula na classe NegociacaoTest. Repare que
agora temos um argumento na anotação expected=IllegalArgumentException.class. Isso indica que,
para esse teste ser considerado um sucesso, uma exceção deve ser lançada daquele tipo. Caso contrário
será uma falha:
@Test(expected=IllegalArgumentException.class)
public void naoCriaNegociacaoComDataNula() {
new Negociacao(10, 5, null);
}

Rode os testes. Barrinha vermelha! Já que ainda não verificamos o argumento na classe Negociacao e
ainda não lançamos a exceção:



Vamos alterar a classe Negociacao, para que ela lance a exceção no caso de data nula. No construtor,
adicione o seguinte if:
if (data == null) {
throw new IllegalArgumentException("data nao pode ser nula");
}
this.preco = preco;
this.data = data;
}

Rode novamente os testes.



3) (opcional) Nosso teste para quando não há negociações na CandlestickFactory está verificando apenas
se o volume é zero. Ele também poderia verificar que os outros valores dessa candle são zero.
Modifique o método semNegociacoesGeraCandleComZeros e adicione os asserts faltantes de abertura,
fechamento, mínimo e máximo.
O teste vai parar de passar!
Corrija ele da mesma forma que resolvemos o problema para as variáveis abertura e fechamento.
4) (opcional) Um Candlestick pode ter preço máximo menor que o preço mínimo? Não deveria.
Crie um novo teste, o CandlestickTest, da maneira que fizemos com o Negociacao. É boa prática que
todos os testes da classe X se encontrem em XTest.
Dentro dele, crie o precoMaximoNaoPodeSerMenorQueMinimo e faça um new passando argumentos que
quebrem isso. O teste deve esperar pela IllegalArgumentException.
A ideia é testar se o construtor de Candlestick faz as validações necessárias. Lembre-se que o construtor recebe como argumento Candlestick(abertura, fechamento, minimo, maximo, volume, data),
portanto queremos testar se algo assim gera uma exceção (e deveria gerar):
new Candlestick(10, 20, 20, 10, 10000, Calendar.getInstance());

5) (opcional) Um Candlestick pode ter data nula? Pode ter algum valor negativo?
Teste, verifique o que está errado, altere código para que os testes passem! Pegue o ritmo, essa será sua
rotina daqui para a frente.



6) (opcional) Crie mais dois testes na CandlestickFactoryTest: o negociacoesEmOrdemCrescenteDeValor
e negociacoesEmOrdemDecrescenteDeValor, que devem fazer o que o próprio nome diz.
Agora eles funcionam?

3.11

Para saber mais: Import Estático

Algumas vezes, escrevemos classes que contém muitos métodos e atributos estáticos (finais, como constantes). Essas classes são classes utilitárias e precisamos sempre nos referir a elas antes de chamar um método
ou utilizar um atributo:
import pacote.ClasseComMetodosEstaticos;
class UsandoMetodosEstaticos {
void metodo() {
ClasseComMetodosEstaticos.metodo1();
ClasseComMetodosEstaticos.metodo2();
}
}

Começa a ficar muito chato escrever, toda hora, o nome da classe. Para resolver esse problema, no Java 5.0
foi introduzido o static import, que importa métodos e atributos estáticos de qualquer classe. Usando essa
nova técnica, você pode importar os métodos do exemplo anterior e usá-los diretamente:
import static pacote.ClasseComMetodosEstaticos.*;
class UsandoMetodosEstaticos {
void metodo() {
metodo1();
metodo2();
}
}

Apesar de você ter importado todos os métodos e atributos estáticos da classe ClasseComMetodosEstaticos,
a classe em si não foi importada e, se você tentasse dar new, por exemplo, ele não conseguiria encontrá-la,
precisando de um import normal à parte.
Um bom exemplo de uso são os métodos e atributos estáticos da classe Assert do JUnit:
import static org.junit.Assert.*;
class TesteMatematico {
@Test
void doisMaisDois() {
Capítulo 3 - Testes Automatizados - Para saber mais: Import Estático - Página 49


assertEquals(4, 2 + 2);
}
}

Use os imports estáticos dos métodos de Assert nos testes de unidade que você escreveu.

3.12

Mais exercícios opcionais

1) Crie um teste para o CandleBuilder. Ele possui um grande erro: se só chamarmos alguns dos métodos,
e não todos, ele construirá um Candle inválido, com data nula, ou algum número zerado.
Faça um teste geracaoDeCandleDeveTerTodosOsDadosNecessarios que tente isso. O método geraCandle
deveria lançar outra exception conhecida da biblioteca Java, a IllegalStateException, quando invocado
antes dos seus outros seis métodos já terem sido.
O teste deve falhar. Corrija-o criando booleans que indicam se cada método setter foi invocado, ou utilizando alguma outra forma de verificação.
2) Se você fez os opcionais do primeiro exercício do capítulo anterior (criação do projeto e dos modelos)
você tem os métodos isAlta e isBaixa na classe Candlestick. Contudo, temos um comportamento não
especificado nesses métodos: e quando o preço de abertura for igual ao de fechamento?
Perguntando para nosso cliente, ele nos informou que, nesse caso, o candle deve ser considerado de alta.
Crie o teste quandoAberturaIgualFechamentoEhAlta dentro de CandlestickTest, verifique se isso está
ocorrendo. Se o teste falhar, faça mudanças no seu código para que a barra volte a ficar verde!
3) O que mais pode ser testado? Testar é viciante, e aumentar o número de testes do nosso sistema começa
a virar um hábito divertido e contagioso. Isso não ocorre de imediato, é necessário um tempo para se
apaixonar por testes.

3.13

Discussão em aula: testes são importantes?

Capítulo 3 - Testes Automatizados - Mais exercícios opcionais - Página 50

Capítulo 4

Trabalhando com XML
“Se eu enxerguei longe, foi por ter subido nos ombros de gigantes."
– Isaac Newton

4.1

Os dados da bolsa de valores

Como vamos puxar os dados da bolsa de valores para popular nossos candles?
Existem inúmeros formatos para se trabalhar com diversas bolsas. Sem dúvida XML é um formato comumente encontrado em diversas indústrias, inclusive na bolsa de valores.
Utilizaremos esse tal de XML. Para isso, precisamos conhecê-lo mais a fundo, seus objetivos, e como
manipulá-lo. Considere que vamos consumir um arquivo XML como o que segue:
<list>
<negociacao>
<preco>43.5</preco>
<quantidade>1000</quantidade>
<data>
<time>1222333777999</time>
</data>
</negociacao>
<negociacao>
<preco>44.1</preco>
<data>
<time>1222444777999</time>
</data>


</negociacao>
<negociacao>
<preco>42.3</preco>
<data>
<time>1222333999777</time>
</data>
</negociacao>
</list>

Uma lista de negociações! Cada negociação informa o preço, quantidade e uma data. Essa data é composta
por um horário dado no formato de Timestamp, e opcionalmente um Timezone.

4.2

O formato XML

XML (eXtensible Markup Language) é uma formalização da W3C para gerar linguagens de marcação que
podem se adaptar a quase qualquer tipo de necessidade. Algo bem extensível, flexível, de fácil leitura e
hierarquização. Sua definição formal pode ser encontrada em:
http://www.w3.org/XML/
Exemplo de dados que são armazenados em XMLs e que não conhecemos tão bem, é o formato aberto de
gráficos vetoriais, o SVG (usado pelo Corel Draw, Firefox, Inkscape, etc), e o Open Document Format (ODF),
formato usado pelo OpenOffice, e hoje em dia um padrão ISO de extrema importância. (na verdade o ODF
é um ZIP que contém XMLs internamente).
A ideia era criar uma linguagem de marcação que fosse muito fácil de ser lida e gerada por softwares, e
pudesse ser integrada as outras linguagens. Entre seus princípios básicos, definidos pelo W3C:
• Separação do conteúdo da formatação
• Simplicidade e Legibilidade
• Possibilidade de criação de tags novas
• Criação de arquivos para validação (DTDs e schemas)
O XML é uma excelente opção para documentos que precisam ter seus dados organizados com uma certa
hierarquia (uma árvore), com relação de pai-filho entre seus elementos. Esse tipo de arquivo é dificilmente
organizado com CSVs ou properties. Como a própria imagem do wikipedia nos trás e mostra o uso estruturado e encadeado de maneira hierárquica do XML:

Capítulo 4 - Trabalhando com XML - O formato XML - Página 52


O cabeçalho opcional de todo XML é o que se segue:
<?xml version="1.0" encoding="ISO-8859-1"?>

Esses caracteres não devem ser usados como elemento, e devem ser “escapados":
• &, use &
• ‘, use '
• “, use "
• <, use <
• >, use >
Você pode, em Java, utilizar a classe String e as regex do pacote java.util.regex para criar um programa
que lê um arquivo XML. Isso é uma grande perda de tempo, visto que o Java, assim como quase toda e
qualquer linguagem existente, possui uma ou mais formas de ler um XML. O Java possui diversas, vamos ver
algumas delas, suas vantagens e suas desvantagens.

4.3

Lendo XML com Java de maneira difícil, o SAX

O SAX (Simple API for XML) é uma API para ler dados em XML, também conhecido como Parser de XML.
Um parser serve para analisar uma estrutura de dados e geralmente o que fazemos é transformá-la em uma
outra.
Neste processo de análise também podemos ler o arquivo XML para procurar algum determinado elemento
e manipular seu conteúdo.
O parser lê os dados XML como um fluxo ou uma sequência de dados. Baseado no conteúdo lido, o parser
vai disparando eventos. É o mesmo que dizer que o parser SAX funciona orientado a eventos.
Existem vários tipos de eventos, por exemplo:
Capítulo 4 - Trabalhando com XML - Lendo XML com Java de maneira difícil, o SAX - Página 53


• início do documento XML;
• início de um novo elemento;
• novo atributo;
• início do conteúdo dentro de um elemento.
Para tratar estes eventos, o programador deve passar um objeto listener ao parser que será notificado automaticamente pelo parser quando um desses eventos ocorrer. Comumente, este objeto é chamado de Handler,
Observer, ou Listener e é quem faz o trabalho necessário de processamento do XML.
public class NegociacaoHandler extends DefaultHandler {
@Override
public void startDocument() throws SAXException {
}
@Override
public void startElement(String uri, String localName,
String name, Attributes attributes) throws SAXException {
// aqui você é avisado, por exemplo
// do inicio da tag "<preco>"
}
@Override
public void characters(char[] chars, int offset, int len)
throws SAXException {
// aqui você seria avisado do inicio
// do conteúdo que fica entre as tags, como por exemplo 30
// de dentro de "<preco>30</preco>"
// para saber o que fazer com esses dados, você precisa antes ter
// guardado em algum atributo qual era a negociação que estava
// sendo percorrida
}
@Override
public void endElement(String uri, String localName, String name)
throws SAXException {
// aviso de fechamento de tag
}
}

A classe DefaultHandler permite que você reescreva métodos que vão te notificar sobre quando um elemento
(tag) está sendo aberto, quando está sendo fechado, quando caracteres estão sendo parseados (conteúdo de


uma tag), etc.. Você é o responsável por saber em que posição do object model (árvore) está, e que atitude
deve ser tomada. A interface ContentHandler define mais alguns outros métodos.

Curiosidade sobre o SAX
Originalmente o SAX foi escrito só para Java e vem de um projeto da comunidade (http://www.
saxproject.org), mas existem outras implementações em C++, Perl e Python.
O SAX está atualmente na versão 2 e faz parte do JAX-P (Java API for XML Processing).
O SAX somente sabe ler dados e nunca modificá-los e só consegue ler para frente, nunca para trás. Quando
passou um determinado pedaço do XML que já foi lido, não há mais como voltar. O parser SAX não guarda
a estrutura do documento XML na memória.
Também não há como fazer acesso aleatório aos itens do documento XML, somente sequencial.
Por outro lado, como os dados vão sendo analisados e transformados (pelo Handler) na hora da leitura, o
SAX ocupa pouca memória, principalmente porque nunca vai conhecer o documento inteiro e sim somente
um pequeno pedaço. Devido também a leitura sequencial, ele é muito rápido comparado com os parsers que
analisam a árvore do documento XML completo.
Quando for necessário ler um documento em partes ou só determinado pedaço e apenas uma vez, o SAX
parser é uma excelente opção.

StAX - Streaming API for XML
StAX é um projeto que foi desenvolvido pela empresa BEA e padronizado pela JSR-173. Ele é
mais novo do que o SAX e foi criado para facilitar o trabalho com XML. StAX faz parte do Java
SE 6 e JAX-P.
Como o SAX, o StAX também lê os dados de maneira sequencial. A diferença entre os dois é a
forma como é notificada a ocorrência de um evento.
No SAX temos que registrar um Handler. É o SAX que avisa o Handler e chama os métodos dele.
Ele empurra os dados para o Handler e por isso ele é um parser do tipo push, .
O StAX, ao contrário, não precisa deste Handler. Podemos usar a API do StAX para chamar seus
métodos, quando e onde é preciso. O cliente decide, e não o parser. É ele quem pega/tira os
dados do StAX e por isso é um parser do tipo pull.
O site http://www.xmlpull.org fornece mais informações sobre a técnica de Pull Parsing, que
tem sido considerada por muitos como a forma mais eficiente de processar documentos xml.
A biblioteca XPP3 é a implementação em Java mais conhecida deste conceito. É usada por outras
bibliotecas de processamento de xml, como o CodeHaus XStream.



4.4

XStream

O XStream é uma alternativa perfeita para os casos de uso de XML em persistência, transmissão de dados e
configuração. Sua facilidade de uso e performance elevada são os seus principais atrativos.
É um projeto hospedado na Codehaus, um repositório de código open source focado em Java, que foi formado por desenvolvedores de famosos projetos como o XDoclet, PicoContainer e Maven. O grupo é patrocinado por empresas como a ThoughWorks, BEA e Atlassian. Entre os desenvolvedores do projeto, Guilherme
Silveira da Caelum está também presente.
http://xstream.codehaus.org
Diversos projetos opensource, como o container de inversão de controle NanoContainer, o framework de
redes neurais Joone, dentre outros, passaram a usar XStream depois de experiências com outras bibliotecas.
O XStream é conhecido pela sua extrema facilidade de uso. Repare que raramente precisaremos fazer configurações ou mapeamentos, como é extremamente comum nas outras bibliotecas mesmo para os casos mais
básicos.
Como gerar o XML de uma negociação? Primeiramente devemos ter uma referência para o objeto. Podemos
simplesmente criá-lo e populá-lo ou então deixar que o Hibernate faça isso.
Com a referência negociacao em mãos, basta agora pedirmos ao XStream que gera o XML correspondente:
Negociacao negociacao = new Negociacao(42.3, 100, Calendar.getInstance());
XStream stream = new XStream(new DomDriver());
System.out.println(stream.toXML(negociacao));

E o resultado é:
<br.com.caelum.argentum.Negociacao>
<preco>42.3</preco>
<data>
<time>1220009639873</time>
<timezone>America/Sao_Paulo</timezone>
</data>
</br.com.caelum.argentum.Negociacao>

A classe XStream atua como façade de acesso para os principais recursos da biblioteca. O construtor da
classe XStream recebe como argumento um Driver, que é a engine que vai gerar/consumir o XML. Aqui
você pode definir se quer usar SAX, DOM, DOM4J dentre outros, e com isso o XStream será mais rápido,
mais lento, usar mais ou menos memória, etc.
O default do XStream é usar um driver chamado XPP3, desenvolvido na universidade de Indiana e conhecido
por ser extremamente rápido (leia mais no box de pull parsers). Para usá-lo você precisa de um outro JAR
no classpath do seu projeto.
Capítulo 4 - Trabalhando com XML - XStream - Página 56


O método toXML retorna uma String. Isso pode gastar muita memória no caso de você serializar uma lista
grande de objetos. Ainda existe um overload do toXML, que além de um Object recebe um OutputStream
como argumento para você poder gravar diretamente num arquivo, socket, etc.
Diferentemente de outros parsers do Java, o XStream serializa por default os objetos através de seus atributos
(sejam privados ou não), e não através de getters e setters.
Repare que o XStream gerou a tag raiz com o nome de br.com.caelum.argentum.Negociacao. Isso porque
não existe um conversor para ela, então ele usa o próprio nome da classe e gera o XML recursivamente para
cada atributo não transiente daquela classe.
Porém, muitas vezes temos um esquema de XML já muito bem definido, ou simplesmente não queremos
gerar um XML com cara de java. Para isso podemos utilizar um alias. Vamos modificar nosso código que
gera o XML:
stream.alias("negociacao", Negociacao.class);

Essa configuração também pode ser feita através da anotação @XStreamAlias("negociacao") em cima da
classe Negociacao.
Podemos agora fazer o processo inverso. Dado um XML que representa um bean da nossa classe Negociacao,
queremos popular esse bean. O código é novamente extremamente simples:
Negociacao n = (Negociacao) stream.fromXML("<negociacao>" +
"<preco>42.3</preco>" +
"<quantidade>100</quantidade>" +
"</negociacao>");
System.out.println(negociacao.getPreco());

Obviamente não teremos um XML dentro de um código Java. O exemplo aqui é meramente ilustrativo (útil
em um teste!). Os atributos não existentes ficarão como null no objeto, como é o caso aqui do atributo data,
ausente no XML.
O XStream possui uma sobrecarga do método fromXML que recebe um InputStream como argumento, outro
que recebe um Reader.

JAXB ou XStream?
A vantagem do JAXB é ser uma especificação do Java, e a do XStream é ser mais flexível e permitir
trabalhar com classes imutáveis.

Capítulo 4 - Trabalhando com XML - XStream - Página 57


@XStreamAlias
Em vez de chamar stream.alias("negociacao", Negociacao.class);, podemos fazer essa
configuração direto na classe Negociacao com uma anotação:
@XStreamAlias("negociacao")
public class Negociacao {
}

Para habilitar o suporte a anotações, precisamos chamar no xstream:
stream.autodetectAnnotations(true);

Ou então, se precisarmos processar as anotações de apenas uma única classe, basta indicá-la,
como abaixo:
stream.processAnnotations(Negociacao.class);

Note que trabalhar com as anotações, portanto, não nos economiza linhas de código. Sua principal vantagem é manter as configurações centralizadas e, assim, se houver mais de uma parte
na sua aplicação responsável por gerar XMLs de um mesmo modelo, não corremos o risco de ter
XMLs incompatíveis.

4.5

Exercícios: Lendo o XML

1) Para usarmos o XStream, precisamos copiar seus JARs para o nosso projeto e adicioná-los ao Build Path.
Para facilitar, vamos criar uma pasta lib para colocar todos os JARs que necessitarmos.
Crie uma nova pasta usando ctrl + N e começando a digitar Folder:

Capítulo 4 - Trabalhando com XML - Exercícios: Lendo o XML - Página 58


Coloque o nome de lib e clique OK:

2) Vamos pôr o XStream no nosso projeto. Vá na pasta Caelum no seu Desktop e entre em 22. Localize o
arquivo do XStream:



Esse é o mesmo arquivo que você encontra para download no site do XStream, na versão minimal.
3) Copie o JAR do XStream 1.4 para a pasta lib/ do Argentum e, pelo Eclipse, entre na pasta lib e dê refresh
(F5) nela.
Então, selecione o JAR, clique com o botão direito e vá em Build Path, Add to build path. A partir de
agora o Eclipse considerará as classes do XStream para esse nosso projeto.

4) Vamos, finalmente, implementar a leitura do XML, delegando o trabalho para o XStream. Criamos a
classe LeitorXML dentro do pacote br.com.caelum.argentum.reader:
package br.com.caelum.argentum.reader;
// imports...
public class LeitorXML {
public List<Negociacao> carrega(InputStream inputStream) {
return (List<Negociacao>) stream.fromXML(inputStream);
}
}

5) Crie um teste de unidade LeitorXMLTest pelo Eclipse para testarmos a leitura do XML. Com o cursor na
classe LeitorXML, faça Ctrl + N e digite JUnit Test Case:
Lembre-se de colocá-lo na source folder src/test/java.
Para não ter de criar um arquivo XML no sistema de arquivos, podemos usar um truque interessante:
coloque o trecho do XML em uma String Java, e passe um ByteArrayInputStream, convertendo nossa
String para byte através do método getBytes():


@Test
public void carregaXmlComUmaNegociacaoEmListaUnitaria() {
String xmlDeTeste = "..."; // o XML vai aqui!
LeitorXML leitor = new LeitorXML();
InputStream xml = new ByteArrayInputStream(xmlDeTeste.getBytes());
List<Negociacao> negociacoes = leitor.carrega(xml);
}

Use o seguinte XML de teste, substituindo a linha em negrito acima:
String xmlDeTeste = "<list>" +
"
<negociacao>" +
"
<preco>43.5</preco>" +
"
<quantidade>1000</quantidade>" +
"
<data>" +
"
<time>1322233344455</time>" +
"
</data>" +
"
</negociacao>" +
"</list>";

6) Um teste de nada serve se não tiver suas verificações. Assim, não esqueça de verificar valores esperados
como:
• a lista devolvida deve ter tamanho 1;
• a negociação deve ter preço 43.5;
• a quantidade deve ser 1000.
7) (Opcional) Crie mais alguns testes para casos excepcionais, como:
• Zero negociações;
• Preço ou quantidade faltando;
• Outras quantidades de negociações (3, por exemplo).
8) (importante, conceitual) E o que falta agora? Testar nosso código com um XML real?
É muito comum sentirmos a vontade de fazer um teste “maior": um teste que realmente abre um
InputStreamReader, passa o XML para o LeitorXML e depois chama a CandlestickFactory para quebrar as negociações em candles.
Esse teste seria um chamado teste de integração - não de unidade. Se criássemos esse teste e ele falhasse,
seria muito mais difícil detectar o ponto de falha!



Pensar em sempre testar as menores unidades possíveis nos força a pensar em classes menos dependentes
entre si, isto é, com baixo acoplamento. Por exemplo: poderíamos ter criado um LeitorXML que internamente chamasse a fábrica e devolvesse diretamente uma List<Candlestick>. Mas isso faria com que o
nosso teste do leitor de XML testasse muito mais que apenas a leitura de XML (já que estaria passando
pela CandlestickFactory).

4.6

Discussão em aula: Onde usar XML e o abuso do mesmo

Capítulo 4 - Trabalhando com XML - Discussão em aula: Onde usar XML e o abuso do mesmo - Página 62

Capítulo 5

Test Driven Design - TDD
“Experiência sem teoria é cegueira, mas teoria sem experiência é mero jogo intelectual."
– Immanuel Kant

5.1

Separando as candles

Agora que temos nosso leitor de XML que cria uma lista com as negociações representadas no arquivo passado, um novo problema surge: a BOVESPA permite fazer download de um arquivo XML contendo todas
as negociações de um ativo desde a data especificada. Entretanto, nossa CandlestickFactory está preparada
apenas para construir candles de uma data específica.
Dessa forma, precisamos ainda quebrar a lista que contém todas as negociações em partes menores, com
negociações de um dia apenas, e usar o outro método para gerar cada Candlestick. Essas, devem ser armazenadas em uma nova lista para serem devolvidas.
Para fazer tal lógica, então, precisamos:
• passar por cada negociações da lista original;
• verificar se continua no mesmo dia e...
• ...se sim, adiciona na lista do dia;
• ...caso contrário:
– gera a candle;
– guarda numa lista de Candlesticks;
– zera a lista de negociações do dia;


– indica que vai olhar o próximo dia, agora;
• ao final, devolver a lista de candles;
O algoritmo não é trivial e, ainda, ele depende de uma verificação que o Java não nos dá prontamente: se
continua no mesmo dia. Isto é, dado que eu sei qual a dataAtual, quero verificar se a negociação pertence a
esse mesmo dia.
Verificar uma negociação é do mesmo dia que um Calendar qualquer exige algumas linhas de código, mas
veja que, mesmo antes de implementá-lo, já sabemos como o método isMesmoDia deverá se comportar em
diversas situações:
• se for exatamente o mesmo milissegundo => true;
• se for no mesmo dia, mas em horários diferentes => true;
• se for no mesmo dia, mas em meses diferentes => false;
• se for no mesmo dia e mês, mas em anos diferentes => false.
Sempre que vamos começar a desenvolver uma lógica, intuitivamente, já pensamos em seu comportamento.
Fazer os testes automatizados para tais casos é, portanto, apenas colocar nosso pensamento em forma de
código. Mas fazê-lo incrementalmente, mesmo antes de seguir com a implementação é o princípio do que
chamamos de Test Driven Design (TDD).

5.2

Vantagens do TDD

TDD é uma técnica que consiste em pequenas iterações, em que novos casos de testes de funcionalidades
desejadas são criados antes mesmo da implementação. Nesse momento, o teste escrito deve falhar, já que
a funcionalidade implementada não existe. Então, o código necessário para que os testes passem, deve ser
escrito e o teste deve passar. O ciclo se repete para o próximo teste mais simples que ainda não passa.
Um dos principais benefício dessa técnica é que, como os testes são escritos antes da implementação do
trecho a ser testado, o programador não é influenciado pelo código já feito - assim, ele tende a escrever testes
melhores, pensando no comportamento em vez da implementação.
Lembremos: os testes devem mostrar (e documentar) o comportamento do sistema, e não o que uma implementação faz.
Além disso, nota-se que TDD traz baixo acoplamento, o que é ótimo já que classes muito acopladas são
difíceis de testar. Como criaremos os testes antes, desenvolveremos classes menos acopladas, isto é, menos
dependentes de outras muitas, separando melhor as responsabilidades.
O TDD também é uma espécie de guia: como o teste é escrito antes, nenhum código do sistema é escrito
por “acharmos” que vamos precisar dele. Em sistemas sem testes, é comum encontrarmos centenas de linhas
que jamais serão invocadas, simplesmente porque o desenvolvedor “achou” que alguém um dia precisaria
daquele determinado método.
Capítulo 5 - Test Driven Design - TDD - Vantagens do TDD - Página 64


Imagine que você já tenha um sistema com muitas classes e nenhum teste: provavelmente, para iniciar a
criação de testes, muitas refatorações terão de ser feitas, mas como modificar seu sistema garantindo o funcionamento dele após as mudanças quando não existem testes que garantam que seu sistema tenha o comportamento desejado? Por isso, crie testes sempre e, de preferência, antes da implementação da funcionalidade.
TDD é uma disciplina difícil de se implantar, mas depois que você pega o jeito e o hábito é adquirido, podemos ver claramente as diversas vantagens dessa técnica.

5.3

Exercícios: Identificando negociações do mesmo dia

Poderíamos criar uma classe LeitorXML que pega todo o XML e converte em candles, mas ela teria muita
responsabilidade. Vamos cuidar da lógica que separa as negociações em vários candles por datas em outro
lugar.
1) Queremos então, em nossa classe de factory, pegar uma série de negociações e transformar em uma lista
de candles. Para isso vamos precisar que uma negociação saiba identificar se é do mesmo dia que a
dataAtual.
Para saber, conforme percorremos todas as negociações, se a negociação atual ainda aconteceu na mesma
data que estamos procurando, vamos usar um método na classe Negociacao que faz tal verificação.
Seguindo os princípios do TDD, começamos escrevendo um teste na classe NegociacaoTest:
@Test
public void mesmoMilissegundoEhDoMesmoDia() {
Calendar agora = Calendar.getInstance();
Calendar mesmoMomento = (Calendar) agora.clone();
Negociacao negociacao = new Negociacao(40.0, 100, agora);
Assert.assertTrue(negociacao.isMesmoDia(mesmoMomento));
}

Esse código não vai compilar de imediato, já que não temos esse método na nossa classe. No Eclipse,
aperte Ctrl + 1 em cima do erro e escolha Create method isMesmoDia.

E qual será uma implementação interessante? Que tal simplificar usando o método equals de Calendar?
Capítulo 5 - Test Driven Design - TDD - Exercícios: Identificando negociações do mesmo dia - Página 65


public boolean isMesmoDia(Calendar outraData) {
return this.data.equals(outraData);
}

Rode o teste! Passa?
2) Nosso teste passou de primeira! Vamos tentar mais algum teste? Vamos testar datas iguais em horas
diferentes, crie o método a seguir na classe NegociacaoTest:
@Test
public void comHorariosDiferentesEhNoMesmoDia() {
// usando GregorianCalendar(ano, mes, dia, hora, minuto)
Calendar manha = new GregorianCalendar(2011, 10, 20, 8, 30);
Calendar tarde = new GregorianCalendar(2011, 10, 20, 15, 30);
Negociacao negociacao = new Negociacao(40.0, 100, manha);
Assert.assertTrue(negociacao.isMesmoDia(tarde));
}

Rode o teste. Não passa!
Infelizmente, usar o equals não resolve nosso problema de comparação.
Lembre que um Calendar possui um timestamp, isso quer dizer que além do dia, do mês e do ano, há
também informações de hora, segundos etc. A implementação que compara os dias será:
return
data.get(Calendar.DAY_OF_MONTH) == outraData.get(Calendar.DAY_OF_MONTH);
}

Altere o método isMesmoDia na classe Negociacao e rode os testes anteriores. Passamos agora?
3) O próximo teste a implementarmos será o que garante que para dia igual, mas mês diferente, a data não
é a mesma. Quer dizer: não basta comparar o campo referente ao dia do mês, ainda é necessário que seja
o mesmo mês!
Crie o mesmoDiaMasMesesDiferentesNaoSaoDoMesmoDia na classe de testes do Negociacao, veja o teste
falhar e, então, implemente o necessário para que ele passe. Note que, dessa vez, o valor esperado é o
false e, portanto, utilizaremos o Assert.assertFalse.
4) Finalmente, o último teste a implementarmos será o que garante que para dia e meses iguais, mas anos
diferentes, a data não é a mesma. Siga o mesmo procedimento para desenvolver com TDD:
• Escreva o teste mesmoDiaEMesMasAnosDiferentesNaoSaoDoMesmoDia;
• Rode e veja que falhou;
• Implemente o necessário para fazê-lo passar.

Capítulo 5 - Test Driven Design - TDD - Exercícios: Identificando negociações do mesmo dia - Página 66


Feito esse processo, seu método isMesmoDia na classe Negociacao deve ter ficado bem parecido com isso:
return
this.data.get(Calendar.DAY_OF_MONTH) == outraData.get(Calendar.DAY_OF_MONTH) &&
this.data.get(Calendar.MONTH) == outraData.get(Calendar.MONTH) &&
this.data.get(Calendar.YEAR) == outraData.get(Calendar.YEAR);
}

5.4

Exercícios: Separando os candles

1) Próximo passo: dada uma lista de negociações de várias datas diferentes mas ordenada por data, quebrar
em uma lista de candles, uma para cada data.
Seguindo a disciplina do TDD: começamos pelo teste!
Adicione

o

método
CandlestickFactoryTest:

paraNegociacoesDeTresDiasDistintosGeraTresCandles

na

classe

@Test
public void paraNegociacoesDeTresDiasDistintosGeraTresCandles() {
Negociacao
Negociacao
Negociacao
Negociacao

negociacao1
negociacao2
negociacao3
negociacao4

=
=
=
=

new
new
new
new

Negociacao(40.5,
Negociacao(45.0,
Negociacao(39.8,
Negociacao(42.3,

100,
100,
100,
100,

hoje);
hoje);
hoje);
hoje);

Calendar amanha = (Calendar) hoje.clone();
amanha.add(Calendar.DAY_OF_MONTH, 1);
Negociacao negociacao5 = new Negociacao(48.8, 100, amanha);
Negociacao negociacao6 = new Negociacao(49.3, 100, amanha);
Calendar depois = (Calendar) amanha.clone();
depois.add(Calendar.DAY_OF_MONTH, 1);
Negociacao negociacao7 = new Negociacao(51.8, 100, depois);
Negociacao negociacao8 = new Negociacao(52.3, 100, depois);
negociacao3, negociacao4, negociacao5, negociacao6, negociacao7,
negociacao8);

Capítulo 5 - Test Driven Design - TDD - Exercícios: Separando os candles - Página 67


List<Candlestick> candles = fabrica.constroiCandles(negociacoes);
Assert.assertEquals(3, candles.size());
Assert.assertEquals(40.5, candles.get(0).getAbertura(), 0.00001);
Assert.assertEquals(42.3, candles.get(0).getFechamento(), 0.00001);
}

A chamada ao método constroiCandles não compila pois o método não existe ainda. Ctrl + 1 e Create
method.
Como implementamos? Precisamos:
• Criar a List<Candlestick>;
• Percorrer a List<Negociacao> adicionando cada negociacão no Candlestick atual;
• Quando achar uma negociação de um novo dia, cria um Candlestick novo e adiciona;
• Devolve a lista de candles;
O código talvez fique um pouco grande. Ainda bem que temos nosso teste!
public List<Candlestick> constroiCandles(List<Negociacao> todasNegociacoes) {
List<Candlestick> candles = new ArrayList<Candlestick>();
List<Negociacao> negociacoesDoDia = new ArrayList<Negociacao>();
Calendar dataAtual = todasNegociacoes.get(0).getData();
for (Negociacao negociacao : todasNegociacoes) {
// se não for mesmo dia, fecha candle e reinicia variáveis
if (!negociacao.isMesmoDia(dataAtual)) {
Candlestick candleDoDia = constroiCandleParaData(dataAtual,
negociacoesDoDia);
candles.add(candleDoDia);
negociacoesDoDia = new ArrayList<Negociacao>();
dataAtual = negociacao.getData();
}
negociacoesDoDia.add(negociacao);
}
// adiciona último candle
Candlestick candleDoDia = constroiCandleParaData(dataAtual,
negociacoesDoDia);
Capítulo 5 - Test Driven Design - TDD - Exercícios: Separando os candles - Página 68


return candles;
}

Rode o teste!

5.5


1) E se passarmos para o método constroiCandles da fábrica uma lista de negociações que não está na
ordem crescente? O resultado vai ser candles em ordem diferentes, e provavelmente com valores errados. Apesar da especificação dizer que os negociações vem ordenados pela data, é boa prática programar
defensivamente em relação aos parâmetros recebidos.
Aqui temos diversas opções. Uma delas é, caso alguma Negociacao venha em ordem diferente da crescente, lançamos uma exception, a IllegalStateException.
Crie o naoPermiteConstruirCandlesComNegociacoesForaDeOrdem e configure o teste para verificar que
uma IllegalStateException foi lançada. Basta usar como base o mesmo teste que tínhamos antes, mas
adicionar as negociações com datas não crescentes.
Rode o teste e o veja falhar.

Pra isso, modificamos o código adicionando as linhas em negrito ao método constroiCandles:
for (Negociacao negociacao : todasNegociacoes) {
if (negociacao.getData().before(dataAtual)) {
Capítulo 5 - Test Driven Design - TDD - Exercícios opcionais - Página 69


throw new IllegalStateException("negociações em ordem errada");
}
// se não for mesmo dia, fecha candle e reinicia variáveis
...

2) Vamos criar um gerador automático de arquivos para testes da bolsa. Ele vai gerar 30 dias de candle e
cada candle pode ser composto de 0 a 19 negociações. Esses preços podem variar.
public class GeradorAleatorioDeXML {
public static void main(String[] args) throws IOException {
Calendar data = Calendar.getInstance();
Random random = new Random(123);
List<Negociacao> negociacoes = new ArrayList<Negociacao>();
double valor = 40;
int quantidade = 1000;
for (int dias = 0; dias < 30; dias++) {
int quantidadeNegociacoesDoDia = random.nextInt(20);
for (int negociacao = 0; negociacao < quantidadeNegociacoesDoDia;
negociacao++){
// no máximo sobe ou cai R$1,00 e nao baixa além de R$5,00
valor += (random.nextInt(200) - 100) / 100.0;
if (valor < 5.0) {
valor = 5.0;
}
// quantidade: entre 500 e 1500
quantidade += 1000 - random.nextInt(500);
Negociacao n = new Negociacao(valor, quantidade, data);
negociacoes.add(n);
}
data = (Calendar) data.clone();
data.add(Calendar.DAY_OF_YEAR, 1);
}
stream.setMode(XStream.NO_REFERENCES);
PrintStream out = new PrintStream(new File("negociacao.xml"));
out.println(stream.toXML(negociacoes));
}


}

Se você olhar o resultado do XML, verá que, por usarmos o mesmo objeto Calendar em vários lugares, o
XStream coloca referências no próprio XML evitando a cópia do mesmo dado. Mas talvez isso não seja
tão interessante na prática, pois é mais comum na hora de integrar sistemas, passar um XML simples com
todos os dados.
A opção XStream.NO_REFERENCES serve para indicar ao XStream que não queremos que ele crie referências
a tags que já foram serializadas iguaizinhas. Você pode passar esse argumento para o método setMode do
XStream. Faça o teste sem e com essa opção para entender a diferença.

Desafio - Ordene a lista on demand
1) Faça com que uma lista de Negociacao seja ordenável pela data das negociações.
Então poderemos, logo no início do método, ordenar todas as negociações com Collections.sort e não
precisamos mais verificar se os negociações estão vindo em ordem crescente!
Perceba que mudamos uma regra de negócio, então teremos de refletir isso no nosso teste unitário que
estava com expected=IllegalStateException.class no caso de vir em ordem errada. O resultado agora
com essa modificação tem de dar o mesmo que com as datas crescentes.


Capítulo 6

Acessando um Web Service
“Nenhum homem é uma ilha isolada; cada homem é uma partícula do continente, uma parte da terra”
– John Donne

6.1

Integração entre sistemas

No capítulo anterior resolvemos o problema de como interpretar os dados oriundos de um arquivo XML,
apesar disso, no mundo real, dados são gerados dinamicamente a todo instante das mais diversas fontes.
No mercado de bolsa de valores é comum o uso de aplicações que permitem aos seus usuários analisar o
mercado, e até mesmo comprar e vender ações em tempo real. Mas como é possível analisar o mercado se
não temos acesso aos dados da Bovespa?
A integração e a comunicação com o sistema da Bovespa se faz necessária para que possamos receber dados
sempre atualizados. Geralmente essa comunicação se dá pelo próprio protocolo da web, o HTTP, com o
formato difundido e já estudado XML. Essa integração e comunicação entre aplicações possui o nome de
Web Service.

6.2

Consumindo dados de um Web Service

Para consumir dados vindos de outra aplicação, a primeira coisa importante é saber onde essa aplicação se
encontra. Em termos técnicos, qual a URL desse web service. Em nosso projeto a URL específica da aplicação
será http://argentumws.caelum.com.br/negociacoes.
Podemos testar essa URL facilmente dentro do navegador, basta copiar e colar na barra de endereço. Ao
executar, o navegador recebe como resposta o XML de negócios que já conhecemos, por exemplo:


6.3

Criando o cliente Java

Já sabemos de onde consumir, resta saber como consumir esses dados pela web. No mundo web trabalhamos
com o conceito de requisição e resposta. Se queremos os dados precisamos realizar uma requisição para
aquela URL, mas como?
Na própria API do Java temos classes que tornam possível essa tarefa. Como é o caso da classe URL que nos
permite referenciar um recurso na Web, seja ele um arquivo ou até mesmo um diretório.
URL url = new URL("http://argentumws.caelum.com.br/negociacoes");

Conhecendo a URL falta agora que uma requisição HTTP seja feita para ela. Faremos isso através do método openConnection que nos devolve um URLConnection. Entretanto, como uma requisição HTTP se faz
necessária, usaremos uma subclasse de URLConnection que é a HttpURLConnection.
HttpURLConnection connection = (HttpURLConnection) url.openConnection();

Dessa conexão pediremos um InputStream que será usado pelo nosso LeitorXML.
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
InputStream content = connection.getInputStream();
List<Negociacao> negociacoes = new LeitorXML().carrega(content);
Capítulo 6 - Acessando um Web Service - Criando o cliente Java - Página 73


Dessa forma já temos em mãos a lista de negociações que era o nosso objetivo principal. Resta agora encapsularmos este código em alguma classe, para que não seja necessário repeti-lo toda vez que precisamos
receber os dados da negociação. Vamos implementar a classe ClienteWebService e nela deixar explícito qual
o caminho da aplicação que a conexão será feita.
public class ClienteWebService {
private static final String URL_WEBSERVICE =
"http://argentumws.caelum.com.br/negociacoes";
}

Por último, e não menos importante, declararemos um método que retorna uma lista de negociações, justamente o que usaremos no projeto.
public List<Negociacao> getNegociacoes() {
URL url = new URL(URL_WEBSERVICE);
HttpURLConnection connection = (HttpURLConnection)url.openConnection();
return new LeitorXML().carrega(content);
}
}

Nossa classe ainda não compila, pois tanto o construtor de URL quanto os métodos de HttpURLConnection
lançam exceções que são do tipo IOException. Vamos tratar o erro e fechar a conexão que foi aberta pelo
método getInputStream, em um bloco finally.
...
HttpURLConnection connection = null;
try {
connection = (HttpURLConnection)url.openConnection();
} catch (IOException e) {
throw new RuntimeException(e);


} finally {
connection.disconnect();
}
}
...

Dessa forma conseguimos nos comunicar com um Web Service e consumir os dados disponibilizados por
ele através de um XML. Esta é uma prática bastante utilizada pelo mercado e estudada com mais aprofundamento no curso FJ-31 | Curso Java EE avançado e Web Services.

HttpClient
Existe uma biblioteca capaz de lidar com dados de uma forma simples e mais específica do que
utilizar diretamente a API do Java. Para trabalhar com o protocolo HTTP há a biblioteca HttpClient que faz parte do Apache Software Foundation:
http://hc.apache.org/httpcomponents-client-ga/index.html
Com ela ganhamos uma API que fornece toda funcionalidade do protocolo HTTP e poderíamos usá-la para chamar o Web Service. Segue um pequeno exemplo usando o HttpClient para
executar uma requisição do tipo GET:
HttpClient client = new DefaultHttpClient();
HttpGet request = new HttpGet(URL_DO_WEBSERVICE);
HttpResponse response = client.execute(request);
InputStream content = response.getEntity().getContent();



Web Service - SOAP, JSON e outros
Por definição um Web Service é alguma lógica de negócio acessível usando padrões da Internet. O mais comum é usar HTTP como protocolo de comunicação e XML para o formato que
apresenta os dados - justamente o que praticaremos aqui. Mas nada impede o uso de outros
formatos.
Uma tentativa de especificar mais ainda o XML dos Web Services são os padrões SOAP e WSDL.
Junto com o protocolo HTTP, eles definem a base para comunicação de vários serviços no
mundo de aplicações Enterprise. O SOAP e WSDL tentam esconder toda comunicação e geração do XML, facilitando assim o uso para quem não conhece os padrões Web. No treinamento
FJ-31 veremos os detalhes sobre publicação e a criação de clientes baseados no Web Services
SOAP/WSDL.
Outro formato bastante popular nos Web Services é o JSON. JSON é parecido com XML, mas
um pouco menos verboso e fácil de usar com JavaScript. JSON ganhou popularidade através das
requisições AJAX e conquistou o seu espaço nos Web Services também. Além de ser bastante
difundido no desenvolvimento mobile por ser mais leve no tráfego via rede.

6.4

Exercícios: Nosso cliente Web Service

1) Vamos agora implementar o cliente do Web Service, primeiramente criaremos a classe
ClienteWebService, dentro do pacote br.com.caelum.argentum.ws na pasta src/main/java. Vamos criar também uma constante com a URL para onde será feita a requisição.
}

2) Agora vamos criar o método getNegociacoes(), que retorna a nossa lista de negociações:

Capítulo 6 - Acessando um Web Service - Exercícios: Nosso cliente Web Service - Página 76


}
}

3) Não podemos esquecer de colocar o try/catch para tratar possíveis erros e logo em seguida fechar a
conexão:
try {
} catch (IOException e) {
} finally {
connection.disconnect();
}
}
}

6.5

Discussão em aula: Como testar o cliente do web service?

Capítulo 6 - Acessando um Web Service - Discussão em aula: Como testar o cliente do web service? - Página 77

Capítulo 7

Introdução ao JSF e Primefaces
“Eu não temo computadores, eu temo é a falta deles”
– Isaac Asimov

7.1

Interfaces gráficas para o usuário - GUI

Usuários se habituaram com aplicações Desktop durante muitos anos. Este tipo de aplicação é instalada no
computador local e acessa diretamente um banco de dados ou gerenciador de arquivos. As tecnologias típicas
para criar uma aplicação Desktop são Delphi, VB (Visual Basic) ou, no mundo Java, Swing.
Para o desenvolvedor, a aplicação Desktop é construída com uma série de componentes que a plataforma de
desenvolvimento oferece para cada sistema operacional. Esses componentes ricos e muitas vezes sofisticados
estão associados a eventos ou procedimentos que executam lógicas de negócio.
Problemas de validação de dados são indicados na própria tela sem que qualquer informação do formulário
seja perdida. De uma forma natural, esses componentes lembram-se dos dados do usuário, inclusive entre
telas e ações diferentes.
Nesse tipo de desenvolvimento são utilizados diversos componentes ricos, como por exemplo, calendários,
menus diversos ou componentes drag and drop (arrastar e soltar). Eles ficam associados a eventos/ações e
guardam automaticamente seu estado, pois mantêm os valores digitados pelo usuário.


Esses componentes não estão, contudo, associados exclusivamente ao desenvolvimento de aplicações Desktop. Podemos criar a mesma sensação confortável para o cliente em uma aplicação web, também usando
componentes ricos e reaproveitáveis.

7.2

O cliente gordo e o desenvolvimento Desktop

Existem algumas desvantagens nessa abordagem, visto que cada usuário possui uma cópia, muitas das vezes integral, dessa aplicação. Qualquer alteração precisaria ser propagada para todas as outras máquinas.
Estamos usando um cliente gordo, com muita responsabilidade no lado do cliente.

Capítulo 7 - Introdução ao JSF e Primefaces - O cliente gordo e o desenvolvimento Desktop - Página 79


Para piorar, as regras de negócio rodam no computador do usuário, sendo muito difícil depurar a aplicação.
Em geral, enfrentamos problemas de manutenção e gerenciabilidade.

7.3

O desenvolvimento Web e o protocolo HTTP

Para resolver problemas como esse, surgiram as aplicações baseadas na web. Nessa abordagem há um servidor central, onde a aplicação é executada e processada, e todos os clientes podem acessá-la através do
protocolo HTTP.
O usuário precisa basicamente instalar um navegador web, como Firefox ou Internet Explorer, que receberá
o HTML, o CSS e o JavaScript, que afinal são tecnologias que ele entende.
Entre cada requisição (request), trafega o HTML do lado servidor (Server Side) para o computador do cliente
(Client Side). Em nenhum momento a aplicação está salva no cliente. Todas as regras da aplicação estão
sendo processadas no lado do servidor. Por isso, essa abordagem também foi chamada de cliente magro.

Capítulo 7 - Introdução ao JSF e Primefaces - O desenvolvimento Web e o protocolo HTTP - Página 80


Isso facilita bastante a manutenção e a gerenciabilidade, pois temos um lugar - central -, onde a aplicação
é executada, mas ainda é preciso conhecer bastante de HTML, CSS e JavaScript para definir a interface
com o usuário. Também não há mais eventos, mas sim um modelo bem diferente orientado a requisição e
resposta. Além disso, ainda é preciso conhecer o protocolo HTTP. Assim, toda essa responsabilidade fica a
cargo do desenvolvedor.
Comparando as duas abordagens, podemos ver vantagens e desvantagens em ambas. No lado da aplicação
puramente Desktop, temos um estilo de desenvolvimento orientado ao evento, usando componentes ricos,
porém com problemas de manutenção e gerenciamento. Do outro lado, as aplicações web são mais fáceis
de gerenciar e manter, mas precisamos lidar com HTML e conhecer o protocolo HTTP, e seguir o modelo
request-response (requisição-resposta).

7.4

Mesclar desenvolvimento Desktop e Web

O ideal seria mesclar os dois estilos, aproveitando as vantagens de cada um. Seria um desenvolvimento
Desktop para WEB, central e com componentes ricos, seguindo as boas práticas de orientação de objetos mas
sem problemas de manutenção e gerenciabilidade. Isso é justamente a ideia dos frameworks web baseados
em componentes.
No mundo Java há algumas opções como JavaServer Faces (JSF), Apache Wicket, Vaadin, Tapestry ou GWT
da Google. Todos eles são frameworks web baseados em componentes.

7.5

Especificação e implementação do JSF

JSF é uma tecnologia que nos permite criar aplicações Java para Web utilizando componentes visuais, fazendo
com que o desenvolvedor não se preocupe com Javascript e HTML. Basta adicionarmos os componentes
(calendários, tabelas, formulários) que eles serão renderizados e exibidos em formato html.

Guarda o estado dos componentes
Além disso o estado dos componentes é sempre guardado automaticamente (como veremos mais a frente),
fazendo o papel de Stateful. Isso nos permite, por exemplo, criar wizards e navegar nos vários passos dessa
wizard com o estado das telas sendo mantidos, sem ter que resgatá-los novamente.

Separa as camadas
Outra característica marcante na arquitetura do JSF é a separação que fazemos entre as camadas de apresentação e de aplicação. Pensando no modelo MVC, o JSF possui uma camada de visualização que, por padrão,
se baseia nos Facelets e um conjunto de classes conhecidas como Managed Beans; ambos veremos com mais
detalhes.

Capítulo 7 - Introdução ao JSF e Primefaces - Mesclar desenvolvimento Desktop e Web - Página 81


É uma especificação Java EE
Analisando um pouco melhor o JSF, percebemos que ele é na verdade um padrão ou especificação que faz
parte do Java Enterprise Edition (Java EE). Por ser uma especificação, ou Java Specification Request (JSR),
ele é mantido dentro do Java Community Process (JCP).
O JSF 2 foi lançado em Julho de 2009 através da JSR 314. No lançamento do Java EE 6 em Dezembro de
2009, passou a ser oficial na plataforma Java EE. A especificação do JSF pode ser acessada no site da JCP:
http://jcp.org/en/jsr/detail?id=314
Nesse site é mostrado a versão 2.0 do JSF e todos os documentos disponíveis para os interessados na implementação dessa especificação JSF.

Várias implementações
Baseado nesta especificação, há várias implementações. A mais famosa, e também implementação referencial
(RI), é a Oracle Mojarra disponível em http://javaserverfaces.java.net/, aquela que mostra como o JSF deveria
se comportar. Outra implementação famosa é da Apache Software Foundation, e se chama MyFaces (http:
//myfaces.apache.org/).

Neste treinamento usaremos a implementação referencial Mojarra. Acessando o site http://javaserverfaces.
java.net, na parte de downloads, podemos encontrar o JAR do Mojarra.

7.6

Introdução ao JSF com Mojarra e PrimeFaces

Como dito antes, nosso projeto utilizará a implementação Mojarra do JSF. Ela já define o modelo de desenvolvimento e oferece alguns componentes bem básicos. Nada além de inputs, botões e ComboBox simples.
Não há componentes sofisticados dentro da especificação. Isto é proposital, pois o mundo web evolui rápido
(principalmente na questão das interfaces gráficas).
Os componentes da especificação JSF são bem simples:

Capítulo 7 - Introdução ao JSF e Primefaces - Introdução ao JSF com Mojarra e PrimeFaces - Página 82


Para atender a demanda dos desenvolvedores por componentes mais sofisticados, existem várias extensões
do JSF que seguem o mesmo ciclo e modelo da especificação. Exemplos dessas bibliotecas são: PrimeFaces,
RichFaces ou IceFaces. Todas elas definem componentes JSF, mas muito além da especificação.

Cada biblioteca oferece ShowCases na web para mostrar seus componentes e suas funcionalidades. O showcase do PrimeFaces está disponível em http://www.primefaces.org.
Podemos ver na demo online uma lista de componentes disponíveis entre eles inputs, paneis e botões diversos, menus e charts e componentes drag & drop, muito além da especificações, porém mantendo a facilidade
de uso:



Para a definição da interface do projeto Argentum usaremos Oracle Mojarra com PrimeFaces, uma combinação muito comum no mercado.

7.7

Preparação do ambiente

Nossa aplicação Argentum precisa de uma interface web. Para isso vamos preparar uma aplicação web comum
que roda dentro de um Servlet Container.

Tomcat como Servlet Container
Usaremos Apache Tomcat 7, no entanto, poderia ser utilizado qualquer outro servlet container como por
exemplo Jetty.

Configuração do controlador do JSF
JSF segue o padrão arquitetural MVC (Model-View-Controller) por isso precisamos configurar o servlet do
JSF no web.xml da aplicação que representa o controller (C) dentro do modelo MVC. Esse Servlet é responsável em receber as requisições e delegá-las ao core do JSF. Para configurá-lo basta adicionar as seguintes
configurações no web.xml:
<servlet>
<servlet-name>FacesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
Capítulo 7 - Introdução ao JSF e Primefaces - Preparação do ambiente - Página 85


<servlet-name>FacesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>

Ao usar o Eclipse com suporte a JSF 2 essa configuração no web.xml já é feita automaticamente.

Faces-config: o arquivo de configuração do mundo JSF
Além disso, há um segundo XML que é o arquivo de configuração relacionado com o mundo JSF, o
faces-config.xml.
Como o JSF na versão dois encoraja o uso de anotações invés de configurações no XML, este arquivo torna-se
pouco usado, sendo muito mais importante na primeira versão do JSF. Para este treinamento não usaremos
o arquivo, ficando então vazio:
<faces-config
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
</faces-config>

Agora já temos as informações necessárias para criar nosso primeiro projeto utilizando JSF.

7.8

Exercícios: Instalando o Tomcat e criando o projeto

1) Primeiramente, precisamos instalar o Tomcat. Usaremos a versão 7.x:
a) Vá no Desktop e entre na pasta Caelum e em seguida na pasta 22.
b) Descompacte o arquivo apache-tomcat-7.x.x.zip no seu Desktop. Para isso dê um duplo clique no
arquivo para abrir o Archive Manager e clique em Extract.

Capítulo 7 - Introdução ao JSF e Primefaces - Exercícios: Instalando o Tomcat e criando o projeto - Página 86


c) Na janela que abriu, selecione no lado esquerdo o item Desktop e clique em Extract.

d) O Tomcat já está pronto para o uso.
2) O próximo passo é configurar o Tomcat no Eclipse, para que possamos controlá-lo mais facilmente.
a) Abra o Eclipse, e ao ser perguntado sobre o caminho da sua workspace apenas confirme.

b) Dentro do Eclipse, abra a aba Servers. Para isso, pressione CTRL + 3, digite servers e pressione [ENTER]. Ela será aberta na parte inferior do seu Eclipse.
c) Dentro da aba Servers clique com o botão direito do mouse e escolha New -> Server.



d) Dentro da Janela New Server escolha Apache Tomcat v7.0 Server e clique em Next.

e) O próximo passo é dizermos ao Eclipse em qual diretório instalamos o Tomcat. Clique no botão
Browse... e escolha a pasta na qual você descompactou o Tomcat.


f) Clique em Finish.
3) O próximo passo para podermos começar a trabalhar é criar o nosso projeto no Eclipse.
a) Dentro do Eclipse, vá ao menu File -> New -> Dynamic Web Project

b) Em Project name coloque fj22-argentum-web.



c) Na seção Configuration clique em Modify para acrescentarmos suporte ao JSF.
d) Na tela que abre, marque o checkbox com JavaServer Faces e versão 2.0, depois clique OK:

e) De volta à tela de criação do projeto, clique em Next três vezes até chegar à tela de configuração do
JSF. Nessa tela, escolha a opção Disable Library Configuration (isso indica para o Eclipse que nós
mesmos copiaremos os JARs do JSF). Ainda nessa tela, na parte URL Mapping Patterns, remova o
mapeamento /faces/*, se existir, e adicione um novo mapeamento como *.xhtml


f) Clique em Finish e o projeto está criado.
g) Agora, vamos adicionar o projeto ao servidor Tomcat. Na aba Servers, clique com o botão direito sobre
o nome do servidor e escolha a opção Add and Remove...:

h) Na tela seguinte, selecione o projeto fj22-argentum-web no box Available (da esquerda), pressione o
botão Add > (moverá para o box Configured da direita) e depois Finish.



i) Agora precisamos importar o projeto anterior, classes como Negociacao ou Candlestick. Já o temos pronto na pasta Desktop/caelum/22/, com o nome de modelo-argentum.zip, copie-o para o seu
Desktop.Para importá-lo, dê um clique com o botão direito sobre o nosso projeto atual, e em seguida,
Import > Import.... E selecione Archive File.

j) Em Browse..., selecione o nosso arquivo modelo-argentum.zip e finalize-o.


k) Agora precisamos remover o src do Build Path. Então, dê um clique com o direito sobre o diretório
src e vá até Build path > Configure Build Path. Feito isto, clicaremos na aba Source, selecione fj22argentum-web/src, e após isto, remova-o, clicando no botão Remove.

l) Precisamos adicionar nossos diretórios src/main/java e src/test/java no projeto. Para isto, dê um
clique em Add Folder..., e marque as devidas caixas, assim como na imagem abaixo:



Dê OK, e depois OK novamente.
m) Nossas classes de teste (src/test/java) apresentam problemas, e eles estão relacionados ao JUnit, pois
o mesmo não foi adicionado ao Build Path. Abra a classe ClandlestickFactoryTest, do pacote
br.com.caelum.argentum.modelo e sobre a anotação @Test, dê um simples CTRL + 1 e faça como
na imagem abaixo, salvando as alterações.

7.9

A primeira página com JSF 2

As nossas páginas estarão em arquivos com a extensão .xhtml. Dessa forma, criaremos um arquivo chamado
index.xhtml.

Capítulo 7 - Introdução ao JSF e Primefaces - A primeira página com JSF 2 - Página 94

As tag libraries core e html
Os componentes do JSF são usados através de tags novas na nossa tela. O JSF já define dois conjuntos principais de tags (tag library) que vamos utilizar, a core e a html.
A html possui os componentes necessários para montarmos a nossa tela gerando o HTML adequado. Enquanto a core possui diversos componentes não visuais, como por exemplo, tratadores de eventos ou validadores.

Importando as tags em nossa página
Para importar todas essas tags, no nosso arquivo .xhtml, basta declararmos como namespace XML do nosso
arquivo. Dessa forma, teremos:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">

</html>

Utilizando a implementação Mojarra
O JSF é uma especificação e como foi dito utilizaremos a implementação do Projeto Mojarra. Para isto, copiaremos o JAR do Mojarra (javax.faces-2.x.x.jar) da pasta Desktop/caelum/22/jsf-jars para a pasta
WebContent/WEB-INF/lib. Assim os taglibs do namespace serão encontrados.
O JAR do Mojarra também está disponível em http://javaserverfaces.java.net/.

Definindo a interface da aplicação
Vamos começar a definir a interface para a aplicação fj22-argentum-web e criar nossa primeira tela utilizando o JSF. Colocaremos uma mensagem de boas vindas para o usuário.
Como todo arquivo HTML, tudo o que será renderizado no navegador deve ficar dentro de uma Tag body.
Utilizaremos a Tag h:head para definirmos o cabeçalho da página contendo o título dela e também a Tag
h:body na qual colocaremos o conteúdo da nossa página.

Primeiro componente, o h:outputText
Utilizaremos nosso primeiro componente, o h:outputText. É através do seu atributo value que definimos
o texto que será apresentado na página.
Capítulo 7 - Introdução ao JSF e Primefaces - A primeira página com JSF 2 - Página 95


Juntando tudo, nosso primeiro exemplo é uma tela simples com um campo de texto:
<h:head>
<title>Argentum Web</title>
</h:head>
<h:body>
<h:outputText value ="Olá JSF!" />
</h:body>
</html>

7.10

Exercícios: Os primeiros componentes JSF

1) Ao importamos nosso projeto fj22-argentum-web, já temos na pasta WebContent/WEB-INF/lib os JARs
do JSF (javax.faces-2.x.x.jar) e do Primefaces (primefaces-3.x.jar).
Caso esteja seguindo esses passos em casa, é possível fazer o download dos JARs do JSF e do primefaces
nos sites oficiais dos projetos: https://javaserverfaces.dev.java.net/ e http://primefaces.org
2) Em WebContent, crie um arquivo chamado index.xhtml através do menu File -> New -> Other -> HTML.
Após definir o nome do arquivo clique em Next e você verá a seguinte tela:

Capítulo 7 - Introdução ao JSF e Primefaces - Exercícios: Os primeiros componentes JSF - Página 96


Selecione a mesma opção da imagem acima e pressione Finish.
Implemente nosso primeiro código JSF com apenas uma saída de texto:
<h:head>
</h:head>
<h:body>
<h:outputText value ="Olá JSF!" />
</h:body>
</html>

3) Inicie o Tomcat e acesse a URL: http://localhost:8080/fj22-argentum-web/index.xhtml
4) Verifique o código fonte gerado pela página. Repare que ele não é nada mais que simples HTML. Para
isso, nos navegadores Firefox ou Chrome pressione CTRL + U.

Capítulo 7 - Introdução ao JSF e Primefaces - Exercícios: Os primeiros componentes JSF - Página 97


Repare no uso das tags <h:head>, <h:body> e <h:outputText>. Elas gerarão o código HTML necessário
para o exemplo funcionar.

7.11

Listagem de Negociações com Primefaces

Pretendemos usar Primefaces para a definição da interface web devido aos componentes muitos mais sofisticados e funcionais. Para usar os componentes devemos copiar o JAR do Primefaces primefaces-3.X.jar
da pasta Desktop/Caelum/22/jsf-jar para a pasta WebContent/WEB-INF/lib e declarar o namespace do
mesmo no arquivo XHTML. Repare o novo namespace xmlns:p="http://primefaces.org/ui:
xmlns:h="http://java.sun.com/jsf/html"
xmlns:p="http://primefaces.org/ui">
...
</html>

O JAR do Primefaces também está disponível em http://primefaces.org.
Com isso já podemos usufruir os componentes ricos do Primefaces, por exemplo, usando um simples painel
(p:panel) na página:
<html ...>
<h:head>
</h:head>
<h:body>
<p:panel header="Negociações" footer="Argentum Web">
<h:outputText value="Olá JSF!" />
</p:panel>
</h:body>
</html>

Capítulo 7 - Introdução ao JSF e Primefaces - Listagem de Negociações com Primefaces - Página 98


7.12

Código atrás da tela - Managed Beans

Nosso objetivo é listar as negociações do Web Service na tela. O componente que usaremos para a listagem
se chama p:dataTable. O p:dataTable recebe uma lista pelo atributo value. Nesse atributo devemos usar a
Expression Language (EL) que define a classe e o método que fornece a lista de negociações. Diferentemente
da EL do JSP, a EL do JSF começa com #{expression} (tralha):
<p:dataTable value="#{nomeDaClasse.nomeDoMetodoQueDevolveALista}" >
</p:dataTable>

Essas classes ligadas à tela se chamam Managed Beans. São classes simples (ou POJOs) que devem utilizar
uma anotação com o mesmo nome: @ManagedBean. Na nossa aplicação vamos criar um Managed Bean com
nome ArgentumBean:
@ManagedBean
public class ArgentumBean {
}

Agora falta implementar um getter que devolva uma lista de negociações. Nesse método vamos usar a classe
ClienteWebService que chama Web Service:
@ManagedBean
ClienteWebService cliente = new ClienteWebService();
return cliente.getNegociacoes();
}
}

Isso já basta para chamar o método na página pelo componente p:dataTable. Repare que usaremos a Expression Language seguindo a nomenclatura Java Beans, ou seja o método não usa o prefixo get:
<p:dataTable var="negociacao" value="#{argentumBean.negociacoes}">
</p:dataTable>
Capítulo 7 - Introdução ao JSF e Primefaces - Código atrás da tela - Managed Beans - Página 99


O JSF chama o método getNegociacoes várias vezes durante uma requisição. Como é custoso chamar o Web
Service, vamos garantir que ele será inicializado apenas quando o Managed Bean for criado. O JSF prevê para
isso um método especial que deve ser anotado com a anotação @PostConstruct. Esse método é chamado
apenas uma vez, na criação da classe ArgentumBean. Como o bean é instanciado em cada requisição (Request
Scope), o método é chamado uma vez por request:
@ManagedBean
private List<Negociacao> negociacoes;
@PostConstruct
public void preparaDados() {
this.negociacoes = cliente.getNegociacoes();
}
return this.negociacoes;
}
}

Caso queiramos colocar a Managed Bean na sessão Http basta usar a anotação @SessionScoped em cima da
classe:
@ManagedBean
@SessionScoped
//código omitido
}

Com a classe ArgentumBean criado vamos completar a tabela na página. O próximo passo é definir uma
variável que representa uma negociação:
<p:dataTable var="negociacao" value="#{argentumBean.negociacoes}" >
</p:dataTable>

Com essa negociação em mãos podemos declarar o quê queremos apresentar em cada coluna. A tag p:column
define o cabeçalho e recebe o conteúdo da coluna. Repare que imprimimos o preço, volume e a data da
negociação corrente em cada coluna:

Capítulo 7 - Introdução ao JSF e Primefaces - Código atrás da tela - Managed Beans - Página 100


<p:column headerText="Preço" >
<h:outputText value="#{negociacao.preco}" />
</p:column>
<p:column headerText="Quantidade">
<h:outputText value="#{negociacao.quantidade}" />
</p:column>
<p:column headerText="Volume">
<h:outputText value="#{negociacao.volume}" />
</p:column>
<p:column headerText="Data">
<h:outputText value="#{negociacao.data}" />
</p:column>
</p:dataTable>

POJO (Plain Old Java Object)
POJO é um termo criado por Martin Fowler, Rebecca Parsons e Josh MacKenzie que serve para
definir um objeto simples. Segundo eles, o termo foi criado pois ninguém usaria objetos simples
nos seus projetos pois não existia um nome extravagante para ele.

7.13

Formatação de Data com JSF

A tabela já é funcional, mas com a data mal formatada. O componente não sabe como gostaríamos de formatar a data e chama por de baixo dos planos o método toString da data para receber uma apresentação
como String.
Podemos facilmente mudar este comportamento usando o componente f:convertDateTime que define um
pattern para a data. É importante saber que o f:convertDateTime só aceita objetos do tipo java.util.Date,
por isso chamaremos o método getTime da data. Mais uma vez podemos omitir a palavra “get” com expression language. Segue a tabela completa:
</p:column>

Capítulo 7 - Introdução ao JSF e Primefaces - Formatação de Data com JSF - Página 101

</p:column>
</p:column>
<p:column headerText="Data">
<h:outputText value="#{negociacao.data.time}" >
<f:convertDateTime pattern="dd/MM/yyyy" />
</h:outputText>
</p:column>
</p:dataTable>

7.14

Paginação e Ordenação das negociações

O componente p:dataTable não só sabe listar os negociações, ele já vem com várias outras funções prontas e
fáceis de usar. Primeiramente vamos habilitar a paginação automática usando o atributo paginator="true"
e definir a quantidade de linhas por página pelo atributo rows. Veja a definição da tabela:
<p:dataTable var="negociacao" value="#{argentumBean.negociacoes}"
paginator="true" rows="15">

</p:dataTable>

Além disso, vamos deixar as colunas ordenáveis através do simples atributo sortBy. Para a ordenação funcionar é preciso colocar a tabela dentro de um formulário (h:form). Veremos mais para frente como os
formulários funcionam com mais detalhe:
<h:form id="listaNegociacao">
<p:column sortBy="#{negociacao.preco}" headerText="Preço" >
</p:column>


Capítulo 7 - Introdução ao JSF e Primefaces - Paginação e Ordenação das negociações - Página 102


</p:dataTable>
<h:form>

Usando todas as colunas do nosso modelo Negociacao temos um resultado mais atraente:

Isso são apenas algumas das muitas funcionalidades que o p:dataTable oferece. Vale a pena verificar o
showcase e documentação no site do Primefaces.

7.15

Exercícios: p:dataTable para listar as Negociações do
Web Service

1) Como já termos os JARs necessários adicionados ao projeto, para usar os componentes do Primefaces, devemos declarar o namespace do mesmo no arquivo index.xhtml. Acrescente o namespace
xmlns:p="http://primefaces.org/ui”:
2) Agora, o próximo passo é preparar o Managed Bean. Ainda no projeto fj22-argentum-web, pasta
src/main/java, crie uma nova classe ArgentumBean dentro da pacote br.com.caelum.argentum.bean.
Use a anotação @ManagedBean e @SessionScoped em cima da classe:
package br.com.caelum.argentum.bean;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
@ManagedBean
@SessionScoped
Capítulo 7 - Introdução ao JSF e Primefaces - Exercícios: p:dataTable para listar as Negociações do Web Service - Página 103

}

3) Na classe ArgentumBean crie um método preparaDados. Nele chamaremos o Web Service para inicializar
a lista de negociações. Para garantir que o JSF chame o método na criação do bean usaremos a anotação
@PostConstruct:
@PostConstruct
}

4) Falta gerar um getter para o atributo negociacoes. Na classe digite getN e aperte Ctrl+Espaço para usar
o auto-complete do Eclipse:
return negociacoes;
}

5) Abra novamente a página index.xhtml que se encontra na pasta WebContent. Dentro da tag <h:body>,
coloque o componente <p:panel> e remova o componente <h:outputText> do exercício anterior:
<h:body>
</p:panel>
</h:body>

6) Ainda na página index.xhtml, adicione o formulário com a tabela dentro do componente p:panel:
<h:form id="listaNegociacao">

</p:dataTable>
</h:form>

7) Dentro do componente p:dataTable adicione as três primeiras colunas :
</p:column>


</p:column>
</p:column>

8) Reinicie o Tomcat e acesse em seu navegador o endereço http://localhost:8080/fj22-argentum-web/index.
xhtml. O resultado deve ser algo parecido com:

9) Vamos colocar paginação na tabela. Adicione os atributos paginator="true" e rows="15". A definição
da tabela fica como (a primeira parte já existe, adicione somente os últimos dois atributos):

Salve a página e acesse no seu navegador o endereço http://localhost:8080/fj22-argentum-web/index.xhtml.

10) (opcional) Deixe as colunas ordenáveis, use o atributo sortBy em cada atributo, Por exemplo, para a
coluna que mostra o preço da negociação:



<p:column sortBy="#{negociacao.preco}" headerText="Preço" >
</p:column>

Repare que usamos dentro do sortBy expression language (#{negociacao.preco}) para definir o valor a
ordenar.
Salve a página e acesse novamente em seu navegador: http://localhost:8080/fj22-argentum-web/index.xhtml
11) (opcional) Adicione mais uma coluna para a data da negociação. Para formatar a data usaremos um novo
componente f:convertDateTime que recebe um pattern.
<p:column sortBy="#{negociacao.data}" headerText="Data">
<h:outputText value="#{negociacao.data.time}" >
<f:convertDateTime pattern="dd/MM/yyyy" />
</h:outputText>
</p:column>

7.16

O Padrão Model View Controller

Generalizando o modelo acima, podemos dar nomes a cada uma das partes dessa nossa arquitetura. Quem
é responsável por apresentar os resultados na página web é chamado de Apresentação (View).
O responsável em ligar a View com o modelo, neste caso o ManagedBean, atua como um Controlador
(Controller).
As classes que representam suas entidades e as que te ajudam a armazenar e buscar os dados são chamadas
de Modelo (Model).
Esses três formam um padrão arquitetural chamado de MVC, ou Model View Controller. Ele pode sofrer
variações de diversas maneiras. O que o MVC garante é a separação de tarefas, facilitando assim a reescrita
de alguma parte, e a manutenção do código.
Capítulo 7 - Introdução ao JSF e Primefaces - O Padrão Model View Controller - Página 106


A figura abaixo ilustrar o modelo MVC.

Capítulo 7 - Introdução ao JSF e Primefaces - O Padrão Model View Controller - Página 107

Capítulo 8

Refatoração: os Indicadores da bolsa
“Nunca confie em um computador que você não pode jogar pela janela.”
– Steve Wozniak

8.1

Análise Técnica da bolsa de valores

A Análise Técnica Grafista é uma escola econômica que tem como objetivo avaliar o melhor momento para
compra e venda de ações através da análise histórica e comportamental do ativo na bolsa.
Essa forma de análise dos dados gerados sobre dados das negociações (preço, volume, etc), usa gráficos na
busca de padrões e faz análise de tendências para tentar prever o comportamento futuro de uma ação.
A análise técnica surgiu no início do século 20, com o trabalho de Charles Dow e Edward Jones. Eles criaram
a empresa Dow Jones & Company e foram os primeiros a inventarem índices para tentar prever o comportamento do mercado de ações. O primeiro índice era simplesmente uma média ponderada de 11 ativos famosos
da época, que deu origem ao que hoje é conhecido como Dow-Jones.
A busca de padrões nos candlesticks é uma arte. Através de critérios subjetivos e formação de figuras, analistas podem determinar, com algum grau de acerto, como o mercado se comportará dali para a frente.
Munehisa Homna, no século 18, foi o primeiro a pesquisar os preços antigos do arroz para reconhecer padrões. Ele fez isso e começou a criar um catálogo grande de figuras que se repetiam.
A estrela da manhã, Doji, da figura abaixo, é um exemplo de figura sempre muito buscada pelos analistas:


Ela indica um padrão de reversão. Dizem que quando o preço de abertura e fechamento é praticamente igual
(a estrela), essa é uma forte indicação de que o mercado se inverta, isto é, se estava em uma grande baixa,
tenderá a subir e, se estava em uma grande alta, tenderá a cair.

8.2

Indicadores Técnicos

Uma das várias formas de se aplicar as premissas da análise técnica grafista é através do uso de indicadores
técnicos. Indicadores são fórmulas que manipulam dados das negociações e tiram valores deles em busca
de informações interessantes para recomendar as próximas ações para um ativo. Esse novo número, é determinístico e de fácil cálculo por um computador. É até de praxe que analistas financeiros programem diversas
dessas fórmulas em macros VBScript, para vê-las dentro do Excel.
É comum, na mesma visualização, termos uma combinação de gráficos, indicadores e até dos candles:

Capítulo 8 - Refatoração: os Indicadores da bolsa - Indicadores Técnicos - Página 109


Uma lista com os indicadores mais usados e como calculá-los pode ser encontrada em: http://stockcharts.
com/school/doku.php?id=chart_school:technical_indicators
Diversos livros também são publicados sobre o assunto. Os principais homebrokers fornecem softwares que
traçam esses indicadores e muitos outros.

8.3

As médias móveis

Há diversos tipos de médias móveis usadas em análises técnicas e elas são frequentemente usadas para investidores que fazem compras/vendas em intervalos muito maiores do que o intervalo de recolhimento de
dados para as candles. As médias mais famosas são a simples, a ponderada, a exponencial e a Welles Wilder.
Vamos ver as duas primeiras, a média móvel simples e a média móvel ponderada.

Média móvel simples
A média móvel simples calcula a média aritmética de algum indicar do papel (em geral o valor de fechamento)
para um determinado intervalo de tempo. Basta pegar todos os valores, somar e dividir pelo número de dias.
A figura a seguir mostra duas médias móveis simples: uma calculando a média dos últimos 50 dias e outra
dos últimos 200 dias. O gráfico é do valor das ações da antiga Sun Microsystems em 2001.

Capítulo 8 - Refatoração: os Indicadores da bolsa - As médias móveis - Página 110


Repare que a média móvel mais ‘curta’, a de 50 dias, responde mais rápido aos movimentos atuais da ação,
mas pode gerar sinais errados a médio prazo.
Em geral, estamos interessados na média móvel dos últimos N dias e queremos definir esse dia inicial. Por
exemplo, para os dados de fechamento abaixo:
DIA
dia
dia
dia
dia
dia
dia
dia
dia

1:
2:
3:
4:
5:
6:
7:
8:

FECHAMENTO
31
32
33
34
33
35
34
33

Vamos fazer as contas para que o indicador calcule a média para os 3 dias anteriores ao dia que estamos
interessados. Por exemplo: se pegamos o dia 6, a média móvel simples para os últimos 3 dias é a soma do
dia 4 ao dia 6: (34 + 33 + 35) / 3 = 34. A média móvel do dia 3 para os últimos 3 dias é 2: (31 + 32 + 33) / 3. E
assim por diante.



O gráfico anterior das médias móveis da Sun pega, para cada dia do gráfico, a média dos 50 dias anteriores.

Média móvel ponderada
Outra média móvel muito famosa é a ponderada. Ela também leva em conta os últimos N dias a partir da data
a ser calculada. Mas, em vez de uma média aritmética simples, faz-se uma média ponderada onde damos
mais peso para o valor mais recente e vamos diminuindo o peso dos valores conforme movemos para valores
mais antigos.
Por exemplo, para os dias a seguir:
DIA
dia
dia
dia
dia
dia
dia
dia
dia

1:
2:
3:
4:
5:
6:
7:
8:

FECHAMENTO
11
12
14
18
15
13
12
16

Vamos calcular a média móvel para os últimos 3 dias, onde hoje tem peso 3, ontem tem peso 2 e anteontem
tem peso 1. Se calcularmos a média móvel ponderada para o dia 6 temos: (13*3 + 15*2 + 18*1) / 6 = 14.50.



A média ponderada nos dá uma visão melhor do que está acontecendo no momento com a cotação da minha
ação, mostrando com menos importância os resultados “atrasados”, portanto menos relevantes para minhas
decisões de compra e venda atuais. Essa média, contudo, não é tão eficiente quando estudamos uma série a
longo prazo.

8.4

Exercícios: criando indicadores

1) O cálculo de uma média móvel é feito a partir de uma lista de resumos do papel na bolsa. No nosso caso,
vamos pegar vários Candlesticks, um para cada dia, e usar seus valores de fechamento.
Para encapsular a lista de candles e aproximar a nomenclatura do código à utilizada pelo cliente no dia a
dia, vamos criar a classe SerieTemporal no pacote br.com.caelum.argentum.modelo:
public class SerieTemporal {
private final List<Candlestick> candles;
public SerieTemporal(List<Candlestick> candles) {
this.candles = candles;
}
public Candlestick getCandle(int i) {
return this.candles.get(i);
}
public int getTotal() {
return this.candles.size();
}
}

Capítulo 8 - Refatoração: os Indicadores da bolsa - Exercícios: criando indicadores - Página 113


MediaMovelSimples,
dentro
do
novo
pacote
br.com.caelum.argentum.indicadores. Essa classe terá o método calcula que recebe a posição
a ser calculada e a SerieTemporal que proverá os candles. Então, o método devolverá a média simples

2) Vamos

criar

a

classe

dos fechamentos dos dois dias anteriores e o atual.
Comece fazendo apenas o cabeçalho desse método:
public class MediaMovelSimples {
public double calcula(int posicao, SerieTemporal serie) {
return 0;
}
}

A ideia é passarmos para o método calcula a SerieTemporal e o dia para o qual queremos calcular a média
móvel simples. Por exemplo, se passarmos que queremos a média do dia 6 da série, ele deve calcular a
média dos valores de fechamento dos dias 6, 5 e 4 (já que nosso intervalo é de 3 dias).
Como essa é uma lógica um pouco mais complexa, começaremos essa implementação pelos testes.
3) Seguindo a ideia do TDD, faremos o teste antes mesmo de implementar a lógica da média. Assim como
você já vem fazendo, use o ctrl + N -> JUnit Test Case para criar a classe de teste MediaMovelSimplesTest
na source folder src/test/java, pacote br.com.caelum.argentum.indicadores.
Então, crie um teste para verificar que a média é calculada corretamente para a sequência de fechamentos
1, 2, 3, 4, 3, 4, 5, 4, 3.
Note que, para fazer tal teste, será necessário criar uma série temporal com candles cujo fechamento
tenha tais valores. Criaremos uma outra classe para auxiliar nesses testes logo em seguida. Por hora, não
se preocupe com o erro de compilação da 5a. linha do código abaixo:
1

public class MediaMovelSimplesTest {

2
3
4
5
6
7

@Test
public void sequenciaSimplesDeCandles() throws Exception {
SerieTemporal serie =
GeradorDeSerie.criaSerie(1, 2, 3, 4, 3, 4, 5, 4, 3);
MediaMovelSimples mms = new MediaMovelSimples();

8
9
10
11
12
13
14
15

Assert.assertEquals(2.0, mms.calcula(2, serie), 0.00001);
Assert.assertEquals(10.0/3, mms.calcula(4, serie), 0.00001);



}

16
17

}

4) Ainda é necessário fazer esse código compilar! Note que, pelo que escrevemos, queremos chamar um
método estático na classe GeradorDeSerie que receberá diversos valores e devolverá a série com Candles
respectivas.
Deixe que o Eclipse o ajude a criar essa classe: use o ctrl + 1 e deixe que ele crie a classe para você e,
então, adicione a ela o método criaSerie, usando o recurso de varargs do Java para receber diversos
doubles.

Varargs
A notação double... valores (com os três pontinhos mesmo!) que usaremos no método a
seguir é indicação do uso de varargs. Esse recurso está presente desde o Java 5 e permite que
chamemos o método passando de zero a quantos doubles quisermos! Dentro do método, esses
argumentos serão interpretados como um array.
Varargs vieram para oferecer uma sintaxe mais amigável nesses casos. Antigamente, quando
queríamos passar um número variável de parâmetros de um mesmo tipo para um método, era
necessário construir um array com esses parâmetros e passá-lo como parâmetro.
Leia mais sobre esse recurso em: http://docs.oracle.com/javase/1.5.0/docs/guide/language/
varargs.html
Na classe GeradorDeSerie, faça o seguinte método (atenção: não é necessário copiar o comentário):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/**
* Serve para ajudar a fazer os testes.
*
* Recebe uma sequência de valores e cria candles com abertura, fechamento,
* minimo e maximo iguais, mil de volume e data de hoje. Finalmente, devolve
* tais candles encapsuladas em uma Serie Temporal.
**/
public static SerieTemporal criaSerie(double... valores) {
List<Candlestick> candles = new ArrayList<Candlestick>();
for (double d : valores) {
candles.add(new Candlestick(d, d, d, d, 1000,
Calendar.getInstance()));
}
return new SerieTemporal(candles);
}

Agora que ele compila, rode a classe de teste. Ele falha, já que a implementação padrão simplesmente


devolve zero!
5) Volte à classe principal MediaMovelSimples e implemente agora a lógica de negócio do método calcula,
que já existe. O método deve ficar parecido com o que segue:
1

public class MediaMovelSimples {

2

double soma = 0.0;
for (int i = posicao - 2; i <= posicao; i++) {
Candlestick c = serie.getCandle(i);
soma += c.getFechamento();
}
return soma / 3;
}

3
4
5
6
7
8
9
10
11

}

Repare que iniciamos o for com posicao - 2. Isso significa que estamos calculando a média móvel dos
últimos 3 dias. Mais para frente, existe um exercício opcional para parametrizar esse valor.
6) Crie a classe MediaMovelPonderada análoga a MediaMovelSimples. Essa classe dá peso 3 para o dia atual,
peso 2 para o dia anterior e o peso 1 para o dia antes desse. O código interno é muito parecido com o da
média móvel simples, só precisamos multiplicar sempre pela quantidade de dias passados.
A implementação do método calcula deve ficar bem parecida com isso:
1

public class MediaMovelPonderada {

2

double soma = 0.0;
int peso = 1;

3
4
5
6

Candlestick c = serie.getCandle(i);
soma += c.getFechamento() * peso;
peso++;
}
return soma / 6;

7
8
9
10
11
12

}

13
14

}

Repare que o peso começa valendo 1 e vai sendo incrementado. O último dia deve ter peso 3, que é o
tamanho do nosso intervalo.
A divisão por 6 no final é a soma dos pesos para o intervalo de 3 dias (3 + 2 + 1 = 6).
7) Depois a classe MediaMovelPonderada deve passar pelo seguinte teste:



public class MediaMovelPonderadaTest {
@Test
public void sequenciaSimplesDeCandles() {
SerieTemporal serie =
GeradorDeSerie.criaSerie(1, 2, 3, 4, 5, 6);
MediaMovelPonderada mmp = new MediaMovelPonderada();
//ex: calcula(2): 1*1 + 2*2
Assert.assertEquals(14.0/6,

+3*3 = 14. Divide por 6, da 14/6
mmp.calcula(2, serie), 0.00001);

}
}

Rode o teste e veja se passamos!
8) (opcional) Crie um teste de unidade em uma nova classe SerieTemporalTest, que verifique se essa classe
pode receber uma lista nula. O que não deveria poder.
Aproveite o momento para pensar quais outros testes poderiam ser feitos para essa classe.

8.5

Refatoração

“Refatoração é uma técnica controlada para reestruturar um trecho de código existente, alterando sua
estrutura interna sem modificar seu comportamento externo. Consiste em uma série de pequenas
transformações que preservam o comportamento inicial. Cada transformação (chamada de refatoração)
reflete em uma pequena mudança, mas uma sequência de transformações pode produzir uma significante
reestruturação. Como cada refatoração é pequena, é menos provável que se introduza um erro. Além disso, o
sistema continua em pleno funcionamento depois de cada pequena refatoração, reduzindo as chances do
sistema ser seriamente danificado durante a reestruturação.”
– Martin Fowler
Em outras palavras, refatoração é o processo de modificar um trecho de código já escrito, executando pequenos passos (baby-steps) sem modificar o comportamento do sistema. É uma técnica utilizada para melhorar
a clareza do código, facilitando a leitura ou melhorando o design do sistema.
Note que para garantir que erros não serão introduzidos nas refatorações, bem como para ter certeza de
que o sistema continua se comportando da mesma maneira que antes, a presença de testes é fundamental.
Com eles, qualquer erro introduzido será imediatamente apontado, facilitando a correção a cada passo da
refatoração imediatamente.
Algumas das refatorações mais recorrentes ganharam nomes que identificam sua utilidade (veremos algumas
nas próximas seções). Além disso, Martin Fowler escreveu o livro Refactoring: Improving the Design of
Capítulo 8 - Refatoração: os Indicadores da bolsa - Refatoração - Página 117


Existing Code, onde descreve em detalhes as principais.
Algumas são tão corriqueiras, que o próprio Eclipse inclui um menu com diversas refatorações que ele é
capaz de fazer por você:

8.6

Exercícios: Primeiras refatorações

1) Temos usado no texto sempre o termo candle em vez de Candlestick. Essa nomenclatura se propagou
no nosso dia-a-dia, tornando-se parte do nosso modelo. Refatore o nome da classe Candlestick para
Candle no pacote br.com.caelum.argentum.modelo.
Dica: Use ctrl + shift + T para localizar e abrir as classes.
Há várias formas de se fazer isso no Eclipse. Pelo Package Explorer, podemos selecionar a classe e apertar
F2. Ou, se estivermos dentro da classe, podemos colocar o cursor sobre o nome dela e usar o atalho alt
+ shift + R, que renomeia classes, métodos, variáveis, etc.

Capítulo 8 - Refatoração: os Indicadores da bolsa - Exercícios: Primeiras refatorações - Página 118


2) No método calcula da classe MediaMovelSimples, temos uma variável do tipo Candle que só serve para
que peguemos o fechamento desse objeto. Podemos, então, deixar esse método uma linha menor fazendo
o inline dessa variável!
Na linha 4 do método abaixo, coloque o cursor na variável c e use o alt + shift + I. (Alternativamente,
use ctrl + 1 Inline local variable)
1
2
3
4
5
6
7
8

double soma = 0.0;
Candle c = serie.getCandle(i);
soma += c.getFechamento();
}
return soma / 3;
}

O novo código, então ficará assim:
double soma = 0.0;
soma += serie.getCandle(i).getFechamento();
}
return soma / 3;
}

Não esqueça de tirar os imports desnecessários (ctrl + shift + O)!
3) Finalmente, abra a classe CandlestickFactory e observe o método constroiCandles. Escrevemos esse
método no capítulo de XML com um algoritmo para separar todos os negócios em vários candles.
No meio desse código, contudo, há um pequeno bloco de código que se repete duas vezes, dentro e fora
do for:
Candle candleDoDia = constroiCandleParaData(dataAtual, negociacoesDoDia);

Se encontramos códigos iguais pelo nosso código, as boas práticas de orientação a objetos nos dizem para
isolar então essa parte repetida em um novo método que, além de poder ser chamado várias vezes, ainda
tem um nome que ajuda a compreender o algoritmo final.


No Eclipse, podemos aplicar a refatoração Extract Method. Basta ir até a classe CandlestickFactory e
selecionar essas linhas de código dentro do método constroiCandles e usar o atalho alt + shift + M,
nomeando o novo método de criaEGuardaCandle e clique em OK.

Repare como a IDE resolve os parâmetros e ainda substitui as chamadas ao código repetido pela chamada
ao novo método.
4) No método constroiCandleParaData, observe que no bloco de código dentro do for invocamos
negociacao.getPreco() quatro vezes.
// ...
if (negociacao.getPreco() > maximo) {
maximo = negociacao.getPreco();
}
if (negociacao.getPreco() < minimo) {
minimo = negociacao.getPreco();
}
}
// ...

Uma forma de deixar o código mais limpo e evitar chamadas desnecessárias seria extrair para uma variável
local.


Para isso, usaremos a refatoração Extract Local Variable através do Eclipse. Selecione a primeira chamada
para negociacao.getPreco() e pressione alt + shift + L.
Um box vai aparecer perguntando o nome da variável que será criada, mantenha o nome aconselhado
pelo Eclipse e pressione OK.
O Eclipse vai alterar o código de forma que fique parecido com:
// ...
double preco = negociacao.getPreco();
if (preco > maximo) {
maximo = preco;
}
if (preco < minimo) {
minimo = preco;
}
}
// ...

Observe que o Eclipse automaticamente substituiu as outras chamadas à negociacoes.getPreco() por
preco.
5) (Opcional) Aproveite e mude os nomes das outras classes que usam a palavra Candlestick: a Factory e
os Testes.

Refatorações disponíveis
Para quem está começando com a usar o Eclipse, a quantidade de atalhos pode assustar. Note,
contudo, que os atalhos de refatoração começam sempre com alt + shift!
Para ajudar um pouco, comece memorizando apenas o atalho que mostra as refatorações disponíveis dado o trecho de código selecionado: alt + shift + T.

8.7

Refatorações maiores

As refatorações que fizemos até agora são bastante simples e, por conta disso, o Eclipse pôde fazer todo o
trabalho para nós!
Há, contudo, refatorações bem mais complexas que afetam diversas classes e podem mudar o design da
Capítulo 8 - Refatoração: os Indicadores da bolsa - Refatorações maiores - Página 121


aplicação. Algumas refatorações ainda mais complexas chegam a modificar até a arquitetura do sistema!
Mas, quanto mais complexos as mudanças para chegar ao resultado final, mais importante é quebrar essa
refatoração em pedaços pequenos e rodar os testes a cada passo.
No final dos próximos capítulos faremos refatorações que flexibilizam nosso sistema e tornam muito mais
fácil trabalhar com os Indicadores Técnicos que vimos mais cedo.
Exemplos de refatorações maiores são:
• Adicionar uma camada a um sistema;
• Tirar uma camada do sistema;
• Trocar uma implementação doméstica por uma biblioteca;
• Extrair uma biblioteca de dentro de um projeto;
• etc...

8.8

Discussão em aula: quando refatorar?

Capítulo 8 - Refatoração: os Indicadores da bolsa - Discussão em aula: quando refatorar? - Página 122

Capítulo 9

Gráficos interativos com Primefaces
“A única pessoa educada é aquela que aprendeu a aprender e a mudar.”
– Carl Rogers

9.1

Por que usar gráficos?

Nossa aplicação apresenta os dados das negociações tabularmente através do componente p:dataTable.
Além disso, precisaremos apresentar os dados da SerieTemporal graficamente.
Gráficos comprovadamente ajudam no entendimento dos dados e são mais fáceis de analisar do que números
dentro de uma tabela. É mais simples reconhecer padrões de imagens, principalmente para a análise técnica
de valores da bolsa.
Para o projeto argentum, apresentaremos os valores da SerieTemporal em um gráfico de linha, aplicando
algum indicador como abertura ou fechamento. Continuaremos com a biblioteca Primefaces que já vem
com suporte para vários tipos de gráficos.

9.2

Exemplos de Gráficos

O Primefaces já possui uma paleta de componentes para gráficos. É possível utilizá-la para desenhar gráficos
de linha, de barra, de torta, de área, gráficos para atualização dinâmica e até para Candles, entre outros.
Também podemos exportar e animar os gráficos.


9.3

Utilizando o Primefaces

Vamos usar o Primefaces para gerar um gráfico que visualiza a evolução dos valores da série. Nosso projeto
está configurado e já podemos decidir qual gráfico utilizar. Para facilitar a decisão e ao mesmo tempo ver as
possibilidades e tipos de gráficos disponíveis, o showcase do Primefaces nos ajudará muito:
http://www.primefaces.org/showcase/ui/home.jsf
Nele encontramos o resultado final e também o código utilizado para a renderização. Vamos programar usando o componente p:lineChart que deve mostrar os valores de abertura ou de fechamento da
SerieTemporal.

Capítulo 9 - Gráficos interativos com Primefaces - Utilizando o Primefaces - Página 124


O uso de componente é simples, segue o código de exemplo do showcase:
<p:lineChart id="category" value="#{chartBean.categoryModel}" legendPosition="e"
title="Category Chart" minY="0" maxY="200" style="height:300px;margin-top:20px"/>

Além dos atributos para definir o layout (maxY e style) em forma de propriedades CSS, o título (title) e a
posição da legenda (legendPosition), podemos ver que o componente recebe os dados através da Expression
Language chamando o Managed Bean #{chartBean.categoryModel}.

9.4

Propriedades para personalizar o gráfico

Já vimos algumas propriedades do componente p:lineChart, mas existem outras bastante utilizadas, são
elas:
• legendPosition - a posição da legenda - west (w), east (e), south (s), north (n)
• xaxisLabel - nome do eixo X
• yaxisLabel - nome do eixo y
• minX, maxX - mínimo e máximo do valor no eixo X
• minY, maxY - mínimo e máximo do valor no eixo X
• title - o título do gráfico
• fill - true ou false, preenche o gráfico, não renderiza uma linha apenas
• showMarkers - true ou false, habilita detalhes em cada ponto do gráfico
• zoom - true ou false, habilita a funcionalidade de zoom no navegador
Todas as propriedades são opcionais. Na documentação do Primefaces há uma seção dedicada aos gráficos
no qual podemos ver as classes relacionadas, atributos do componentes com exemplos de utilização. Segue
uma parte da documentação oficial do Primefaces:

Capítulo 9 - Gráficos interativos com Primefaces - Propriedades para personalizar o gráfico - Página 125


A documentação do Primefaces está disponível em forma de guia de usuário (PDF) e deve fazer parte do
dia-a-dia do desenvolvedor:
http://www.primefaces.org/documentation.html
Também há o tradicional Javadoc disponível em: http://www.primefaces.org/docs/api/3.5/. Devemos usar
ambos para descobrir funcionalidades e propriedades dos componentes.
No showcase também há um exemplo do uso do Managed Bean, porém para maiores informações é fundamental ter acesso ao Javadoc e à documentação da biblioteca para saber quais classes, atributos e métodos
utilizar.
Capítulo 9 - Gráficos interativos com Primefaces - Propriedades para personalizar o gráfico - Página 126


JSF e CSS
O Primefaces ajuda o desenvolvedor através de seu suporte a temas, mas nem sempre ele é suficiente, inclusive quando há uma equipe de designers responsável em determinar a apresentação
da aplicação.
Apesar de trabalharmos com componentes, no final o que é enviado para o cliente é puro HTML,
sendo assim, é possível aplicar estilos através de CSS para mudar o visual da aplicação.
A Caelum oferece o curso WD-43 | Desenvolvimento Web com HTML, CSS e JavaScript. Voltado ao programador de interfaces preocupado com a semântica perfeita, estilos CSS poderosos
e JavaScripts corretos e funcionais. Um curso dedicado a criar interfaces Web com experiência
rica do usuário, estruturação correta e otimizações.

9.5

Definição do modelo do gráfico

Já temos uma noção de como renderizar gráficos através de um componente so Primefaces. O desenvolvedor
não precisa se preocupar como detalhes de JavaScript, de imagens e de animações. Tudo isso é encapsulado
dentro do componente seguindo boas práticas do mundo OO.
O que o componente não sabe ainda é quais os dados que queremos exibir no gráfico. Para o componente,
esses dados representam o modelo (M), seguindo o padrão MVC.
A classe principal do modelo é a org.primefaces.model.chart.ChartModel e há filhas especializadas
como CartesianChartModel, PieChartModel ou BubbleChartModel. Em nosso projeto utilizaremos o
CartesianChartModel. No Javadoc podemos ver todas as filhas que devemos usar dependendo do gráfico
escolhido:
http://www.primefaces.org/docs/api/3.5/org/primefaces/model/chart/ChartModel.html
Um CartesianChartModel recebe um ou mais ChartSeries. Uma ChartSeries representa uma linha no
gráfico do tipo p:lineChart. Ou seja, são os valores X e Y para renderizar a linha no chart. Como poderíamos
renderizar mais do que uma linha no chart, um ChartModel pode receber várias ChartSerie.
Vejo como fica o código fácil de usar:
ChartSeries serieGrafico = new ChartSeries("Abertura");
serieGrafico.set("dia 1", 20.9);
CartesianChartModel modeloGrafico = new CartesianChartModel();
modeloGrafico.addSeries(serieGrafico);
Capítulo 9 - Gráficos interativos com Primefaces - Definição do modelo do gráfico - Página 127

ChartSeries recebe no construtor o rótulo (label) e através do método set, passamos os valores X, Y. Agora
só falta gerar o modelo do gráfico dentro do ArgentumBean. por exemplo:
@ManagedBean
@SessionScoped
private CartesianChartModel modelo;
@PostConstruct
void preparaDados() {
ChartSeries serieGrafico = new ChartSeries("Abertura");
serieGrafico.set("1", 300.06);
this.modelo = new CartesianChartModel();
this.modelo.addSeries(serieGrafico);
}
return negociacoes;
}
public ChartModel getModeloGrafico() {
return modelo;
}
}

No index.xhtml usaremos o componente p:lineChart da forma mais simples chamando o método
getModeloGrafico do ArgentumBean dentro do p:panel:
<p:lineChart value="#{argentumBean.modeloGrafico}" title="PETR4" />"


Capítulo 9 - Gráficos interativos com Primefaces - Definição do modelo do gráfico - Página 128


9.6

Isolando a API do Primefaces: baixo acoplamento

O que acontecerá se precisarmos criar dois gráficos de indicadores diferentes? Vamos copiar e colar todo
aquele código e modificar apenas as partes que mudam? E se precisarmos alterar algo na geração do modelo?
Essas mudanças serão fáceis se tivermos o código todo espalhado pelo nosso programa?
Os princípios de orientação a objetos e as boas práticas de programação podem nos ajudar nesses
casos. Vamos encapsular a maneira como o modelo do gráfico é criado dentro de uma classe, a
GeradorModeloGrafico.
Essa classe deve ser capaz de gerar o modelo com os dados que quisermos. Mas... se ela receberá os dados
para gerar o gráfico, como receberemos esses dados?
É fácil notar que não é uma boa ideia pedir um CartesianChartModel para quem quiser usar o
CartesianChartModel! Se passarmos um CartesianChartModel, no dia que em precisássemos trocar um
ChartModel por outro o impacto dessa mudança seria muito maior: afetaríamos não apenas essa classe, mas
todas as que a utilizam.
Vamos encapsular inclusive a passagem dos dados para o gráfico: a partir de uma SerieTemporal e do intervalo que desejamos plotar, a própria classe GeradorModeloGrafico se encarregará de traduzir essas informações em um CartesianChartModel:
public class GeradorModeloGrafico {
private SerieTemporal serie;
private int comeco;
private int fim;
public GeradorModeloGrafico(SerieTemporal serie, int comeco, int fim) {
this.serie = serie;
this.comeco = comeco;
this.fim = fim;
}
}

Capítulo 9 - Gráficos interativos com Primefaces - Isolando a API do Primefaces: baixo acoplamento - Página 129


E, quem for usar essa classe, fará:
SerieTemporal serie = criaSerie(1,2,3,4,5,6,7,8,8,9,9,4,3,2,2,2,2);
GeradorModeloGrafico g = new GeradorModeloGrafico(serie, 2, 10);

Repare como esse código de teste não possui nada que o ligue ao ChartModel especificamente. O dia em que
precisarmos mudar, apenas a classe GeradorModeloGrafico será alterada. Encapsulamento!
Vamos encapsular também a geração do ChartSeries. Para criar o gráfico, precisamos colocar algumas informações como título e eixos. E, para desenhar a linha do gráfico, chamaremos o plotaMediaMovelSimples.
private
private
private
private

final SerieTemporal serie;
final int comeco;
final int fim;
CartesianChartModel modeloGrafico;

this.serie = serie;
this.fim = fim;
this.modeloGrafico = new CartesianChartModel();
}
public void plotaMediaMovelSimples() {
MediaMovelSimples indicador = new MediaMovelSimples();
LineChartSeries chartSerie = new LineChartSeries("MMS - Fechamento");
for (int i = comeco; i <= fim; i++) {
double valor = indicador.calcula(i, serie);
chartSerie.set(i, valor);
}
this.modeloGrafico.addSeries(chartSerie);
}
return this.modeloGrafico;
}
}

Vamos analisar esse código detalhadamente. O construtor recebe os dados da série temporal e, além de
gravar essas informações nos atributos, ele cria o objeto que receberá os dados, o CartesianChartModel em
si, que é guardado no atributo modeloGrafico.


O método plotaMediaMovelSimples cria um objeto da MediaMovelSimples e varre a SerieTemporal recebida para calcular o conjunto de dados para o modelo do gráfico.
Por fim, o método getModeloGrafico devolve o modelo. Repare que o retorno é do tipo ChartModel, a classe
mãe do CartesianChartModel. É boa prática deixar nossa classe a mais genérica possível para funcionar com
qualquer tipo de método.
Veja como fica o programa dentro do ArgentumBean:
@ManagedBean
@SessionScoped
private ChartModel modeloGrafico;
@PostConstruct
void preparaDados() {
List<Candle> candles = new CandlestickFactory().constroiCandles(negociacoes);
SerieTemporal serie = new SerieTemporal(candles);
GeradorModeloGrafico gerador =
new GeradorModeloGrafico(serie, 2, serie.getTotal() - 1);
gerador.plotaMediaMovelSimples();
this.modeloGrafico = gerador.getModeloGrafico();
}
}
return this.negociacoes;
}
}

Note que, para quem usa o GeradorModeloGrafico nem dá para saber como ele gera o modelo. É um código
encapsulado, flexível, pouco acoplado e elegante: usa boas práticas de OO.



9.7

Para saber mais: Design Patterns Factory Method e Builder

Dois famosos design patterns do GoF são o Factory Method e o Builder - e estamos usando ambos.
Eles são chamados de padrões de criação (creational patterns), pois nos ajudam a criar objetos complicados.
A factory é usada pelo GeradorDeSerie. A ideia é que criar um objeto SerieTemporal diretamente é complicado. Então criaram um método de fábrica que encapsula essas complicações e já devolve o objeto prontinho
para uso.
O padrão Builder é o que estamos usando na classe GeradorModeloGrafico. Queremos encapsular a criação
complicada do modelo e que pode mudar depois com o tempo. Entra aí o objeto construtor da nossa classe
Builder: seu único objetivo é descrever os passos para criação do nosso objeto final (o gráfico) e encapsular
a complexidade disso.
Leia mais sobre esses e outros Design Patterns no livro do GoF.

Capítulo 9 - Gráficos interativos com Primefaces - Para saber mais: Design Patterns Factory Method e Builder - Página 132


JFreeChart
O JFreeChart é uma biblioteca famosa para desenho de gráficos, independente da tecnologia
JSF. É um projeto de software livre iniciado em 2000 e que tem ampla aceitação pelo mercado,
funcionando até em ambientes Java 1.3.
Além do fato de ser livre, possui a vantagem de ser bastante robusta e flexível. É possível usá-la
para desenhar gráficos de pontos, de barra, de torta, de linha, gráficos financeiros, gantt charts,
em 2D ou 3D e muitos outros. Consegue dar saída em JPG, PNG, SVG, EPS e até mesmo exibir
em componentes Swing.

O site oficial possui links para download, demos e documentação:
http://www.jfree.org/jfreechart/
Existe um livro oficial do JFreeChart escrito pelos desenvolvedores com exemplos e explicações
detalhadas de vários gráficos diferentes. Ele é pago e pode ser obtido no site oficial. Além disso,
há muitos tutoriais gratuitos na Internet.

9.8

Exercícios: Gráficos com Primefaces

src/main/java crie a classe GeradorModeloGrafico
br.com.caelum.argentum.grafico para encapsular a criação do modelo do gráfico.

1) Dentro

da

pasta

no

pacote

Use os recursos do Eclipse para escrever esse código! Abuse do ctrl + espaço, do ctrl + 1 e do ctrl
+ shift + O.
public
//
//
//

class GeradorModeloGrafico {
atributos: serie, comeco, fim e grafico
(todos gerados com Ctrl + 1, conforme você criar o construtor)
importe as classes com Ctrl + Shift + O

Capítulo 9 - Gráficos interativos com Primefaces - Exercícios: Gráficos com Primefaces - Página 133


this.serie = serie;
this.fim = fim;
this.modeloGrafico = new CartesianChartModel();
}
}
}
}
}

2) Vamos usar o GeradorModeloGrafico no ArgentumBean. Abra a classe ArgentumBean e crie um novo
atributo que representa o modelo do gráfico. É preciso importar a classe ChartModel do Primefaces (Ctrl
+ Shift + O):
private ChartModel modeloGrafico;

Gere o getter para este atributo.
Dica: Na classe ArgentumBean escreva getM e aperte Ctrl + Espaço. O Eclipse sugerirá o getter para o
atributo modeloGrafico.
3) Na classe ArgentumBean, procure o método preparaDados.
É neste método que criaremos
uma SerieTemporal baseada na lista de negociações do Web Service.
Depois usaremos o
GeradorModeloGrafico para criar o modelo gráfico:
List<Candle> candles = new CandlestickFactory().constroiCandles(this.negociacoes);
SerieTemporal serie = new SerieTemporal(candles);
new GeradorModeloGrafico(serie, 2, serie.getTotal() - 1);
gerador.plotaMediaMovelSimples();



4) Falta usar o componente para renderizar o gráfico na tela. Abra a página index.xhtml que se encontra na
pasta WebContent.
Na página procure o componente p:panel. Logo depois da abertura da tag do p:panel mas antes do
h:form adicione o componente p:lineChart:
<p:lineChart value="#{argentumBean.modeloGrafico}" legendPosition="e" title="PETR4"/>

Salve a página. Reinicie o Tomcat e acesse em seu navegador: http://localhost:8080/fj22-argentum-web/index.
xhtml


Capítulo 10

Aplicando Padrões de projeto
“Estamos todos na sarjeta, mas alguns de nós estão olhando para as estrelas.”
– Oscar Wilde

10.1

Nossos indicadores e o design pattern Strategy

Nosso gerador de gráficos já está interessante, mas no momento ele só consegue plotar a média móvel simples da série. Nosso cliente certamente precisará de outros indicadores técnicos como o de Média Móvel
Ponderada ou ainda indicadores mais simples como um indicador de Abertura ou de Fechamento.
Esses indicadores, similarmente à MediaMovelSimples, devem calcular o valor de uma posição do gráfico
baseado na SerieTemporal que ele atende.
Então, com o indicador criado, precisaremos que o GeradorModeloGrafico consiga plotar cada um desses
gráficos também. Terminaremos com uma crescente classe GeradorModeloGrafico com métodos extremamente parecidos:
//...
}


}
public void plotaMediaMovelPonderada() {
MediaMovelPonderada indicador = new MediaMovelPonderada();
LineChartSeries chartSerie = new LineChartSeries("MMP - Fechamento");
}
}

//...
}

O problema é que cada vez que criarmos um indicador técnico diferente, um novo método deverá ser criado
na classe GeradorModeloGrafico. Isso é uma indicação clássica de acoplamento no sistema.
Como resolver esses problemas de acoplamento e de código parecidíssimo nos métodos? Será que conseguimos criar um único método para plotar e passar como argumento qual indicador técnico queremos plotar
naquele momento?
A orientação a objetos nos dá a resposta: polimorfismo! Repare que nossos dois indicadores possuem a
mesma assinatura de método, parece até que eles assinaram o mesmo contrato. Vamos definir então a interface Indicador:
public interface Indicador {
public abstract double calcula(int posicao, SerieTemporal serie);
}

Podemos fazer as classes MediaMovelSimples e MediaMovelPonderada implementarem a interface
Indicador. Com isso, podemos criar apenas um método na classe do gráfico que recebe um Indicador
qualquer:
...
public void plotaIndicador(Indicador indicador) {
LineChartSeries chartSerie = new LineChartSeries(indicador.toString());

Capítulo 10 - Aplicando Padrões de projeto - Nossos indicadores e o design pattern Strategy - Página 137


}
}
...
}

Na hora de desenhar os gráficos, chamaremos sempre o plotaIndicador, passando como parâmetro qualquer classe que seja um Indicador:
GeradorModeloGrafico gerador = new GeradorModeloGrafico(serie, 2, 40);
gerador.plotaIndicador(new MediaMovelSimples());
gerador.plotaIndicador(new MediaMovelPonderada());

A ideia de usar uma interface comum é ganhar polimorfismo e poder trocar os indicadores. Se usamos um
Indicador, podemos trocar a classe específica sem mexer em nosso código e ganhamos flexibilidade. Podemos ainda criar novos indicadores que implementem a interface e passá-los para o gráfico sem que nunca
mais mexamos na classe GeradorModeloGrafico.
Por exemplo, imagine que queremos um gráfico simples que mostre apenas os preços de fechamento. Podemos considerar a evolução dos preços de fechamento como um Indicador:
public class IndicadorFechamento implements Indicador {
return serie.getCandle(posicao).getFechamento();
}
}

Ou criar ainda classes como IndicadorAbertura, IndicadorMaximo, etc.
Temos agora vários indicadores diferentes, cada um com sua própria estratégia de cálculo do valor, mas
todos obedecendo a mesma interface: dada uma série temporal e a posição a ser calculada, eles devolvem o
valor do indicador. Esse é o design pattern chamado de Strategy.

Capítulo 10 - Aplicando Padrões de projeto - Nossos indicadores e o design pattern Strategy - Página 138


Design Patterns

Design Patterns são aquelas soluções catalogadas para problemas clássicos de orientação a objetos, como este que temos no momento: encapsular e ter flexibilidade.
A fábrica de Candles apresentada em outro capítulo e o método que nos auxilia a criar séries
para testes na GeradorDeSerie são exemplos, respectivamente, dos padrões Abstract Factory e
Factory Method. No caso que estamos estudando agora, o Strategy está nos ajudando a deixar a
classe GeradorModeloGrafico isolada das diferentes formas de cálculo dos indicadores.

10.2

Exercícios: refatorando para uma interface e usando
bem os testes

1) Já que nossas classes de médias móveis são indicadores técnicos, começaremos extraindo a interface de
um Indicador a partir dessas classes.
Abra a classe MediaMovelSimples e use o ctrl + 3 Extract interface. Selecione o método calcula e dê o
nome da interface de Indicador:
Atenção: A interface deve ficar dentro do pacote br.com.caelum.argentum.indicadores:

Effective Java
Item 52: Refira a objetos pelas suas interfaces
Capítulo 10 - Aplicando Padrões de projeto - Exercícios: refatorando para uma interface e usando bem os testes - Página 139


2) Na classe MediaMovelPonderada coloque agora o implements Indicador nela.
public class MediaMovelPonderada implements Indicador {
...
}

3) Vamos criar também uma classe para, por exemplo, ser o indicador do preço de fechamento, o
IndicadorFechamento, no pacote br.com.caelum.argentum.indicadores, que implementa a interface
Indicador:
@Override
return serie.getCandle(posicao).getFechamento();
}
}

criar o IndicadorAbertura,
também
br.com.caelum.argentum.indicadores, que implementa a interface Indicador:

4) De

maneira

análoga

vamos

no

pacote

public class IndicadorAbertura implements Indicador {
@Override
return serie.getCandle(posicao).getAbertura();
}
}

5) Volte para a classe GeradorModeloGrafico e altere o método plotaMediaMovelSimples usando o atalho
alt + shift + C. Você precisará alterar o nome para plotaIndicador e adicionar um parâmetro. Veja com
atenção o screenshot abaixo:



Ignore o erro e, quando essa refatoração terminar, remova a linha que declarava o indicador. Seu método
terminará assim:
public void plotaIndicador(Indicador indicador) {
LineChartSeries chartSerie = new LineChartSeries(indicador.toString());
}
}

6) Repare que estamos chamando o método toString() do indicador no método plotaIndicador(). Vamos sobrescrevê-lo em todos os indicadores criados.
Sobrescreva na classe MediaMovelSimples:
public class MediaMovelSimples implements Indicador{
....
public String toString() {
return "MMS de Fechamento";
}
}

Sobrescreva na classe MediaMovelPonderada:
public class MediaMovelPonderada implements Indicador{
....
return "MMP de Fechamento";
}
}

Também na classe IndicadorFechamento:
....
return "Fechamento";
}



}

E por último na classe IndicadorAbertura:
public class IndicadorAbertura implements Indicador {
....
return "Abertura";
}

}

10.3


1) Nossos cálculos de médias móveis são sempre para o intervalo de 3 dias. Faça com que o intervalo seja
parametrizável. As classes devem receber o tamanho desse intervalo no construtor e usar esse valor no
algoritmo de cálculo.
Não esqueça de fazer os testes para essa nova versão e alterar os testes já existentes para usar esse cálculo
novo. Os testes já existentes que ficarem desatualizados aparecerão com erros de compilação.
2) Toda refatoração deve ser acompanhada dos testes para garantir que não quebramos nada! Rode os testes
e veja se as mudanças feitas até agora mudaram o comportamento do programa.
Se você julgar necessário, acrescente mais testes à sua aplicação refatorada.

10.4

Indicadores mais Elaborados e o Design Pattern Decorator

Vimos no capítulo de refatoração que os analistas financeiros fazem suas análises sobre indicadores mais elaborados, como por exemplo Médias Móveis, que são calculadas a partir de outros indicadores. No momento,
nossos algoritmos de médias móveis sempre calculam seus valores sobre o preço de fechamento. Mas, e se
quisermos calculá-las a partir de outros indicadores? Por exemplo, o que faríamos se precisássemos da média
móvel simples do preço máximo, da abertura ou de outro indicador qualquer?
Criaríamos classes como MediaMovelSimplesAbertura e MediaMovelSimplesMaximo? Que código colocaríamos lá? Provavelmente, copiaríamos o código que já temos e apenas trocaríamos a chamada do
getFechamento pelo getAbertura e getVolume.
A maior parte do código seria a mesma e não estamos reaproveitando código - copiar e colar código não é
reaproveitamento, é uma forma de nos dar dor de cabeça no futuro ao ter que manter 2 códigos idênticos em
lugares diferentes.
Capítulo 10 - Aplicando Padrões de projeto - Exercícios opcionais - Página 142


Queremos calcular médias móveis de fechamento, abertura, volume, etc, sem precisar copiar essas classes de
média. Na verdade, o que queremos é calcular a média móvel baseado em algum outro indicador. Já temos
a classe IndicadorFechamento e é trivial implementar outros como IndicadorAbertura, IndicadorMinimo,
etc.
A MediaMovelSimples é um Indicador que vai depender de algum outro Indicador para ser calculada (por
exemplo o IndicadorFechamento). Queremos chegar em algo assim:
MediaMovelSimples mms = new MediaMovelSimples(
new IndicadorFechamento());
// ... ou ...
MediaMovelSimples mms = new MediaMovelPonderada(
new IndicadorFechamento());

Repare na flexibilidade desse código. O cálculo de média fica totalmente independente do dado usado e, toda
vez que criarmos um novo indicador, já ganhamos a média móvel desse novo indicador de brinde. Vamos
fazer então nossa classe de média receber algum outro Indicador:
public class MediaMovelSimples implements Indicador {
private final Indicador outroIndicador;
public MediaMovelSimples(Indicador outroIndicador) {
this.outroIndicador = outroIndicador;
}
// ... calcula ...
}

E, dentro do método calcula, em vez de chamarmos o getFechamento, delegamos a chamada para o
outroIndicador:
@Override
double soma = 0.0;
soma += outroIndicador.calcula(i, serie);
}
return soma / 3;
}

Nossa classe MediaMovelSimples recebe um outro indicador que modifica um pouco os valores de saída ele complementa o algoritmo da média! Passar um objeto que modifica um pouco o comportamento do seu
é uma solução clássica para ganhar em flexibilidade e, como muitas soluções clássicas, ganhou um nome
nos design patterns de Decorator.
Capítulo 10 - Aplicando Padrões de projeto - Indicadores mais Elaborados e o Design Pattern Decorator - Página 143


Também é um composite!
Note que, agora, nossa MediaMovelSimples é um Indicador e também tem um outro Indicador.
Já vimos antes outro tipo que se comporta da mesma forma, você se lembra?
Assim como os componentes do Swing, nossa MediaMovelSimples se tornou também um exemplo de Composite.

10.5

Exercícios: Indicadores mais espertos e o Design Pattern
Decorator

1) Faremos uma grande mudança agora: nossas médias devem receber como argumento um outro indicador,
formando o design pattern Decorator, como visto na explicação.
Para isso, crie o construtor padrão (sem parâmetros) da MediaMovelSimples usando o atalho de sua preferência:
a) Comece a escrever o nome da classe e mande autocompletar: Med<ctrl + espaço>;
b) Use o criador automático de construtores: ctrl + 3 Constructor.
2) Modifique o construtor usando o atalho alt + shift + C para adicionar o parâmetro do tipo Indicador
chamado outroIndicador e com valor padrão new IndicadorFechamento().

Agora, com o cursor sobre o parâmetro outroIndicador, faça ctrl + 1 e guarde esse valor em um novo
atributo, selecionando assign parameter to new field.
Capítulo 10 - Aplicando Padrões de projeto - Exercícios: Indicadores mais espertos e o Design Pattern Decorator - Página 144


3) Troque a implementação do método calcula para chamar o calcula do outroIndicador:
double soma = 0.0;
soma += outroIndicador.calcula(i, serie);
}
return soma / 3;
}

4) Lembre que toda refatoração deve ser acompanhada dos testes correspondentes. Mas ao usar a refatoração
do Eclipse no construtor da nossa classe MediaMovelSimples, a IDE evitou que quebrássemos os testes já
passando o IndicadorFechamento como parâmetro padrão para todos eles!
Agora, rode os testes novamente e tudo deve continuar se comportando exatamente como antes da refatoração. Caso contrário, nossa refatoração não foi bem sucedida e seria bom reverter o processo todo.
5) Modifique também a classe MediaMovelPonderada para também ter um Decorator.
Isto é, faça ela também receber um outroIndicador no construtor e delegar a chamada a esse indicador
no seu método calcula, assim como fizemos com a MediaMovelSimples.
6) (opcional)Faça um teste unitário na classe MediaMovelSimplesTest que use receba um
IndicadorAbertura vez do de fechamento. Faça também para máximo, mínimo ou outros que
desejar. Mas lembre-se de implementar os indicadores específicos.

Capítulo 10 - Aplicando Padrões de projeto - Exercícios: Indicadores mais espertos e o Design Pattern Decorator - Página 145

Capítulo 11

Formulários com JSF
11.1

Melhorando a Interface

Até agora, ao acessar a aplicação pelo navegador, o gráfico e a tabela de negociações serão gerados automaticamente. Não há nenhuma forma de personalizar o gráfico, como por exemplo definir o título ou escolher
qual indicador queremos mostrar.
Vamos melhorar a interface e adicionar um formulário que oferece para o usuário as seguintes opções:
• Título do gráfico
• Tipo de indicador (abertura ou fechamento)
• Tipo de média móvel (simples ou ponderada)
Além disso, o formulário deve validar a entrada de dados.

11.2

Componentes de entrada

Para definir o título do gráfico usaremos um simples input. A especificação JSF possui para isso um
componente h:inputText que foi reimplementado pelo Primefaces, sendo necessário utilizar seu prefixo
p:inputText.
É muito comum bibliotecas estenderem a funcionalidade da especificação JSF usando o mesmo nome
do componente adicionando recursos não previstos pela especificação. Já vimos isso com o componente
p:dataTable. O Primefaces estendeu o h:dataTable para, por exemplo, paginar a tabela e ordenar os elementos de maneira muito simples, entre várias outras funcionalidades extras.


Isso também acontece com p:inputText, por exemplo, ele recebe o tema configurado no Primefaces, em
nosso caso, o tema padrão. O tema é composto por um conjunto de CSS’s que dão a aplicação um visual mais
atraente.
Igual aos demais componentes, usaremos expression language para ligar o componente ao nosso
ArgentumBean. Usando o componente p:inputText podemos recuperar o valor que o usuário digitou.
O nosso formulário inicial fica como:
<h:form id="dadosGrafico">
<p:outputLabel for="titulo" value="Título:"/>
<p:inputText id="titulo" value="#{argentumBean.titulo}"/>
</h:form>

É uma boa prática identificar os componentes através do atributo id. Aproveitamos essa id no componente
p:outputLabel dentro do atributo for. Assim o label fica associado com o p:inputText.
A classe ArgentumBean ganhou um atributo do tipo String que representa o titulo, além do getter e setter
para ele:
@ManagedBean
@SessionScoped
private String titulo;
//gettter e setter para o atributo titulo
//outros atributos e métodos omitidos
}

11.3

Submetendo o formulário

Como já vimos, um formulário no mundo JSF é apresentado pela tag h:form. Os componentes de entrada devem estar dentro dessa tag. Para recuperar os valores, associamos os componentes com a classe ArgentumBean
pela Expression Language.
Agora falta ainda chamar algum método na classe ArgentumBean que realmente fará algo com os dados submetidos. Para isso o JSF prevê comandos na especificação. São eles que causam a execução de um método
dentro de um Managed Bean.
Capítulo 11 - Formulários com JSF - Submetendo o formulário - Página 147

Veja o exemplo a seguir:

<h:commandButton action="#{argentumBean.preparaDados}" value="Gerar gráfico" />
</h:form>

Nesse exemplo, associamos o componente h:commandButton com o método preparaDados da classe
ArgentumBean. Repare que usamos no atributo action a Expression Language. Ou seja, é o comando que
define qual método chamar e não o formulário como é o padrão no desenvolvimento que utiliza HTML
diretamente.

O que acontece quando o usuário clica no botão?
Quando o usuário clica no botão Gerar gráfico, o JSF primeiro atribui ao atributo titulo de ArgentumBean
o título digitado no formulário e logo em seguida chama o método preparaDados. Repare que esta ordem é
importante, uma vez que o método pode depender dos dados inseridos pelo usuário.
Também podemos usar mais do que um comando dentro do mesmo formulário. Os comandos podem até
chamar métodos diferentes:
<h:commandButton action="#{argentumBean.listaNegociacoes}"
value="Listar negociações" />
<h:commandButton action="#{argentumBean.preparaDados}"
value="Gerar gráfico" />
</h:form>

Podemos trocar o visual do comando. No lugar de renderizarmos o comando como botão, utilizaremos um
link:
<h:commandLink action="#{argentumBean.listaNegociacoes}"
value="Listar negociações" />
<h:commandLink action="#{argentumBean.geraGrafico}"
value="Gerar gráfico" />
</h:form>

Capítulo 11 - Formulários com JSF - Submetendo o formulário - Página 148


O formulário sempre será submetido com uma requisição do tipo POST. A apresentação do comando (link
ou botão) é apenas um detalhe visual.

h:form sempre usará HTTP POST
É importante saber que diferente da tag form no HTML, o h:form sempre envia uma requisição
HTTP do tipo POST sem a possibilidade de escolher o uma do tipo GET.
Isso ocorre porque o JSF tenta abstrair o mundo HTTP e assim fica mais perto do desenvolvimento Desktop tradicional. Ou seja, não é chamado alguma URL, e sim é utilizado um componente do tipo comando que executa um método ou evento dentro de um Managed Bean.

11.4

Validação com JSF

Podemos agora definir um título para cada geração de gráfico, mas temos um problema: nada impede que o
usuário deixe o título em branco, o que não faz sentido para nossa aplicação.

Preenchimento obrigatório através do atributo required
O JSF vem nos socorrer. Se quisermos tornar o preenchimento do título obrigatório, basta adicionarmos
o atributo required="true" no componente p:inputText. A mesma coisa é válida para o h:inputText da
especificação.
<p:inputText id="titulo" value="#{argentumBean.titulo}" required="true"/>

Quando o formulário for submetido com o título em branco, o JSF automaticamente gerará uma mensagem avisando ao usuário que o campo deve ser preenchido. O problema é que ainda não definimos qual
componente será utilizado para mostrar essa mensagem.

Exibindo mensagens com h:messages
O JSF possui o componente h:messages que exibe para o usuário as mensagens geradas pelo framework,
em nosso caso, as de validação. O objetivo aqui é fazer com que a mensagem de preenchimento obrigatório,
inclusive outras mensagens que possam ser geradas, seja exibida para o usuário:
....
<h:form>
<h:messages />
....

Pronto, quando o formulário for submetido com o campo título em branco o JSF exibirá automaticamente a
mensagem de validação.
Capítulo 11 - Formulários com JSF - Validação com JSF - Página 149

Validando o tamanho do campo
Conseguimos impedir que o usuário deixe em branco o título do gráfico, mas nada impede que ele digite
apenas uma letra, algo que com certeza não será de grande ajuda para quem estiver analisando o gráfico.
Além do simples atributo required, o JSF vem com uma série de validadores que podem ser utilizados com
seus componentes. Utilizaremos o f:validateLength. Ele deve ser adicionado dentro da tag que ele validará:
<p:inputText id="titulo" value="#{argentumBean.titulo}" required="true">
<f:validateLength minimum="3" />
</p:inputText>

O atributo minimum determina o tamanho mínimo do campo, em nosso caso, três.

Validação no lado do servidor
Para o usuário o JSF parece realizar uma validação no lado do cliente, mas na verdade toda validação é feita no lado do servidor. Isso é tão verdade, que não houve a necessidade de JavaScript
no lado do cliente.

Uma alternativa interessante: p:growl
Utilizamos o componente h:messages mensagens. O Primefaces tem uma alternativa interessante, o componente p:growl. Este componente tem a mesma funcionalidade de h:messages, mas sua mensagem flutua
no canto superior direito e desaparece depois de alguns segundos:
....
<h:form>

<p:growl />
....

11.5

Organização dos componentes

Criamos o formulário para o usuário definir os dados do gráfico. Vejamos mais uma vez o código, desta vez,
completo:
Capítulo 11 - Formulários com JSF - Organização dos componentes - Página 150


<p:growl />
<p:outputLabel value="Título:" />
</p:inputText>
<h:commandLink action="#{argentumBean.preparaDados}" value="Gerar gráfico" />
</h:form>

Não há nada errado com este código, mas todos os componentes dentro do h:form serão apresentados na
horizontal:

Organizando os componentes na tela com h:panelGrid
Para melhorar o JSF já possui um componente que ajuda na organização. O h:panelGrid sabe alinhar outros
componentes, ideal para nosso caso. Basta definir a quantidade de colunas que queremos usar dentro do grid
e o componente faz o resto. Segue o mesmo exemplo mas com h:panelGrid:
<p:growl />
<h:panelGrid colunms="2">
<p:outputLabel value="Título:" />
<p:inputText id="titulo" value="#{argentumBean.titulo}"
required="true">
</p:inputText>
</h:panelGrid>
</h:form>

Com o grid definido o comando fica abaixo do input:

Por fim vamos colocar o formulário dentro de um painel, aplicando novamente o componente p:panel:

Capítulo 11 - Formulários com JSF - Organização dos componentes - Página 151

<p:panel header="Dados do gráfico">
<p:growl />

</h:form>
</p:panel>

11.6

Exercícios: Executando lógica e validando entrada

Vamos permitir que o usuário digite o título do gráfico e que não seja aceito valor em branco, inclusive o
tamanho deve ter no mínimo três caracteres.
1) No classe ArgentumBean, crie o atributo que guardará o título digitado pelo usuário:
@ManagedBean
@SessionScoped
private String titulo; //crie os getters e setters
}

2) Abra a página index.xhtml e adicione um label e um componente de entrada para o título do gráfico.
Utilize expression language para ligar o componente de entrada ao atributo “titulo” de ArgentumBean.
Crie um novo formulário dentro de um novo painel.
Logo depois da tag h:body adicione:
<p:panel header="Dados do gráfico">
<h:panelGrid columns="2">
<p:outputLabel for="titulo" value="Título:"/>
<p:inputText id="titulo" value="#{argentumBean.titulo}"/>
</h:panelGrid>
</h:form>
</p:panel>

3) Não podemos deixar que título seja informado em branco, para isso, adicione em p:inputText o atributo
required="true".
Capítulo 11 - Formulários com JSF - Exercícios: Executando lógica e validando entrada - Página 152


...
<p:inputText id="titulo" value="#{argentumBean.titulo}" required="true"/>
...

4) Valide também se o título tem no mínimo três caracteres através da tag f:validateLength:
...
</p:inputText>
...

5) Utilize o componente p:growl do Primefaces para exibir as mensagens de validação. Adicione-o como
primeiro componente dentro de h:form e antes do h:panelGrid. Adicione apenas o p:growl
...
<p:growl/>
<h:panelGrid columns="2">
...

6) Por fim, no componente p:lineChart, altere o atributo title para que ele aponte para o atributo titulo
de ArgentumBean através de expression language:
<p:lineChart value="#{argentumBean.modeloGrafico}" legendPosition="e"
title="#{argentumBean.titulo}" />

7) Precisamos submeter o formulário. Faremos isso através do componente h:commandLink que executará o
método preparaDados de ArgentumBean. Adicione-o logo após o p:inputText do título.
...
...

8) Não queremos mais executar o método preparaDados quando a página for aberta pela primeira vez, deixaremos a execução deste método sob responsabilidade exclusiva do componente h:commandLink.
Comente a anotação @PostConstruct do método preparaDados de ArgentumBean com //:
@ManagedBean
@SessionScoped
...
// @PostConstruct
public void preparaDados()
...

{

Capítulo 11 - Formulários com JSF - Exercícios: Executando lógica e validando entrada - Página 153


9) Como não podemos exibir o gráfico enquanto o ChartModel modeloGrafico estiver null, precisamos
fazer uma pequena modificação na página index.xhtml. Adicione o parâmetro rendered no p:panel do
gráfico conforme abaixo:
<p:panel header="Negociações" footer="Argentum Web"
rendered="#{argentumBean.modeloGrafico != null}">

Desta forma, o painel do gráfico só será exibido depois que o método preparaDados for chamado através
do h:commandLink.
10) Salve a página e reinicie o Tomcat. Teste as alterações: http://localhost:8080/fj22-argentum-web/index.xhtml

11.7

ComboBox para selecionar os indicadores

Permitimos ao usuário definir o título do gráfico, mas isso ainda não é suficiente. Precisamos de alguma
maneira permitir a escolha entre os diferentes tipos de indicadores e médias que já criamos.

Selecionando indicadores e médias com p:selectOneMenu
Para selecionar o indicador base (abertura ou fechamento) e as médias (simples ou ponderada), usaremos
um combo box. Igual ao inputText há um componente da especificação, mas usaremos a reimplementação
do Primefaces que possui um design mais atraente.
O componente se chama p:selectOneMenu e cada opção dentro do combo box é apresentada através de um
f:selectItem. Um f:selectItem recebe um valor e um label. Dessa maneira podemos escrever:
<p:outputLabel for="indicador" value="Indicador:" />
<p:selectOneMenu id="indicador">
<f:selectItem itemValue="IndicadorAbertura" itemLabel="Abertura" />
<f:selectItem itemValue="IndicadorFechamento" itemLabel="Fechamento" />
</p:selectOneMenu>

Novamente seguimos a boa prática de identificar o componente. Falta apenas recuperar o valor selecionado
no ArgentumBean. Sem surpresa, usaremos expression language no componente selectOneMenu dentro do
atributo value.

Capítulo 11 - Formulários com JSF - ComboBox para selecionar os indicadores - Página 154


<p:selectOneMenu id="indicador" value="#{argentumBean.nomeIndicador}">
</p:selectOneMenu>

No ArgentumBean recebemos esse valor como String:
@ManagedBean
@SessionScoped
private String nomeIndicador; //getter e setter
}

Além do design mais elegante, o p:selectOneMenu pode ser criado dinamicamente pelo componente
f:selectItens e possui funcionalidades de filtro e edição. Há vários exemplos no showcase.
O segundo combo box é para as médias. A única diferença é que sua escolha é opcional. Por isso haverá um
componente do tipo f:selectItem com um itemValue vazio. Veja como fica código:
<p:outputLabel value="Média:" for="media" />
<p:selectOneMenu id="media" value="#{argentumBean.nomeMedia}">
<f:selectItem itemValue="" itemLabel="Escolhe um" />
<f:selectItem itemValue="MediaMovelSimples" itemLabel="Simples" />
<f:selectItem itemValue="MediaMovelPonderada" itemLabel="Ponderada" />
</p:selectOneMenu>

Assim como o componente anterior, teremos mais um atributo no ArgentumBean com seus getter e setter:
@ManagedBean
@SessionScoped

Capítulo 11 - Formulários com JSF - ComboBox para selecionar os indicadores - Página 155


private String nomeMedia; //getter e setter
}

11.8

Exercícios: Completando o Formulário

1) Na classe ArgentumBean criaremos mais dois atributos, um para o nome do indicador e outro para a nome
da média. No método vamos apenas imprimir os valores
@ManagedBean
@SessionScoped
//atributos e outros métodos omitidos
private String nomeIndicador; //getter e setter
private String nomeMedia; //getter e setter
//@PostConstruct

{

System.out.println("Indicador: " + nomeIndicador + ", " + nomeMedia);
//implementação omitida
}
}

2) Abra a página index.xhtml que se encontra na pasta WebContent.
Procure a tag p:inputText. Diretamente abaixo dessa tag e antes do h:commandLink vamos criar dois
combo boxes para o nome do indicador e a para o nome da média.
Adicione logo abaixo p:inputText o primeiro h:selectOneMenu:
<p:outputLabel value="Indicador:" for="indicador" />
<p:selectOneMenu id="indicador" value="#{argentumBean.nomeIndicador}">
</p:selectOneMenu>

3) Falta o segundo combo box para escolher a média. Adicione depois do primeiro p:selectOneMenu:
<p:outputLabel value="Média:" for="media" />
<p:selectOneMenu id="media" value="#{argentumBean.nomeMedia}">
<f:selectItem itemValue="" itemLabel="Escolhe um" />

Capítulo 11 - Formulários com JSF - Exercícios: Completando o Formulário - Página 156


<f:selectItem itemValue="MediaMovelSimples" itemLabel="Simples" />
<f:selectItem itemValue="MediaMovelPonderada" itemLabel="Ponderada" />
</p:selectOneMenu>

4) Salve a página e reinicie o Tomcat.

Teste o formulário em seu navegador: http://localhost:8080/

fj22-argentum-web/index.xhtml

Ao submeter o formulário deve aparecer no console do Eclipse o indicador selecionado.
5) Faça mais um teste, e escolha Abertura como indicador e Simples como média. Perceba que a legenda do
gráfico não está condizente com os indicadores e médias que selecionamos. Para melhorar nossa apresentação, vamos mudar a implementação do método toString() tanto na MediaMovelSimples quanto
na MediaMovelPonderada.
public class MediaMovelSimples implements Indicador {
...
return "MMS-" + this.outroIndicador.toString();
}
}
public class MediaMovelPonderada implements Indicador {
...
return "MMP-" + this.outroIndicador.toString();
}
}

Reinicie o Tomcat e faça o mesmo teste anterior. Escolha Abertura como indicador e Simples como média.
O resultado deve ser uma legenda com o texto de: MMS-Abertura.

Capítulo 11 - Formulários com JSF - Exercícios: Completando o Formulário - Página 157

Capítulo 12

API de Reflection
12.1

Montando os indicadores dinamicamente

No nosso formulário criamos dois combo boxes, um para o indicador base e outro para a média. Enquanto
o usuário é obrigado a escolher o indicador, a média é opcional.

Baseado nesse input é preciso montar o(s) indicador(es). Ou seja, pode ser que o usuário queira gerar o
gráfico usando apenas a abertura ou fechamento, como ele também pode combinar com uma média (simples
ou ponderada).
Repare que recebemos no ArgentumBean os dados dos combo boxes como String, e temos dois atributos na
classe:
private String nomeIndicador;
private String nomeMedia;

Para criar os indicadores vamos analisar os dois atributos. A primeira ideia é usar um simples if para descobrir qual é o indicador base:


Indicador indicador = null;
if(nomeIndicador.equals("IndicadorAbertura")) {
indicador = new IndicadorAbertura();
} else {
indicador = new IndicadorFechamento();
}

Além disso, temos que verificar se for selecionado uma média. É preciso testar se o atributo existe (não é
nulo) e qual foi a média:
if (nomeMedia != null) {
if (nomeMedia.equals("MediaMovelSimples")) {
indicador = new MediaMovelSimples(indicador);
} else {
indicador = new MediaMovelPonderada(indicador);
}
}

Portanto nosso código ficaria assim:
Indicador indicador = null;
if (nomeIndicador.equals("IndicadorAbertura")) {
indicador = new IndicadorAbertura();
} else {
indicador = new IndicadorFechamento();
}
if (nomeMedia != null) {
if (nomeMedia.equals("MediaMovelSimples")) {
indicador = new MediaMovelSimples(indicador);
} else {
indicador = new MediaMovelPonderada(indicador);
}
}

Nesse pequeno trecho escrevemos 3 ifs que já é um sinal de um mal design e um aumento na Complexidade
Ciclomática do nosso código.

Capítulo 12 - API de Reflection - Montando os indicadores dinamicamente - Página 159


Complexidade Ciclomática
A ideia é basicamente contar o número de caminhos diferentes que um método pode ter. E
quanto maior esse número for mais testes serão necessários para garantir o funcionamento
esperado. Para maiores detalhes sobre essa métrica consulte no blog da caelum esse artigo:
http://blog.caelum.com.br/medindo-a-complexidade-do-seu-codigo/
Por vantagem competitiva, nosso cliente pede mais indicadores (mínimo e máximo) e outras médias (exponencial e adaptativa). É sensível que o código nunca pára de crescer e é sempre sujeito a alteração.
Nesse caso a API de reflection cai com uma luva. Com ela podemos escrever o código que cria objetos ou
chamar métodos sem conhecer as classes antecipadamente, justamente o que precisamos para montar as
indicadores.

12.2

Introdução a Reflection

Por ser uma linguagem compilada, Java permite que, enquanto escrevemos nosso código, tenhamos total
controle sobre o que será executado, de tudo que faz parte do nosso sistema. Em tempo de desenvolvimento,
olhando nosso código, sabemos quantos atributos uma classe tem, quais construtores e métodos ela possui,
qual chamada de método está sendo feita e assim por diante.
Mas existem algumas raras situações onde essa garantia do compilador não nos ajuda. Isto é, existem situações em que precisamos de características dinâmicas. Por exemplo, imagine permitir que, dado um nome
de método que o usuário passar, nós o invocaremos em um objeto. Ou ainda, que, ao recebermos o nome de
uma classe enquanto executando o programa, possamos criar um objeto dela!
Nesse capítulo você vai conhecer um pouco desse recurso avançado e muito poderoso, que embora possua
qualidades aumenta bastante a complexidade do nosso código e por essa razão deve ser usado de forma
sensata.

12.3

Por que Reflection?

Um aluno que já cursou o FJ-21 pode notar uma incrível semelhança com a discussão em aula sobre MVC,
onde, dado um parâmetro da requisição, criamos um objeto das classes de lógica. Outro exemplo, já visto,
é o do XStream: dado um XML, ele consegue criar objetos para nós e colocar os dados nos atributos dele.
Como ele faz isso? Será que no código-fonte do XStream acharíamos algo assim:
Negociacao n = new Negociacao(...);

O XStream foi construído para funcionar com qualquer tipo de XML e objeto. Com um pouco de ponderação
fica óbvio que não há um new para cada objeto possível e imaginável dentro do código do XStream. Mas
Capítulo 12 - API de Reflection - Introdução a Reflection - Página 160


como ele consegue instanciar um objeto da minha classe e popular os atributos, tudo sem precisar ter new
Negociacao() escrito dentro dele?
O java.lang.reflect é um pacote do Java que permite criar chamadas em tempo de execução, sem precisar conhecer as classes e objetos envolvidos quando escrevemos nosso código (tempo de compilação). Esse
dinamismo é necessário para resolvermos determinadas tarefas que nosso programa só descobre serem necessárias ao receber dados, em tempo de execução.
De volta ao exemplo do XStream, ele só descobre o nome da nossa classe Negociacao quando rodamos o
programa e selecionamos o XML a ser lido. Enquanto escreviam essa biblioteca, os desenvolvedores do
XStream não tinham a menor ideia de que um dia o usaríamos com a classe Negociacao.
Apenas para citar algumas possibilidades com reflection:
• Listar todos os atributos de uma classe e pegar seus valores em um objeto;
• Instanciar classes cujo nome só vamos conhecer em tempo de execução;
• Invocar um construtor especifico baseado no tipo de atributo
• Invocar métodos dinamicamente baseado no nome do método como String;
• Descobrir se determinados pedaços do código têm annotations.

12.4

Constructor, Field e Method

O ponto de partida da reflection é a classe Class. Esta, é uma classe da própria API do Java que representa
cada modelo presente no sistema: nossas classes, as que estão em JARs e também as do próprio Java. Através
da Class conseguimos obter informações sobre qualquer classe do sistema, como seus atributos, métodos,
construtores, etc.
Todo objeto tem um jeito fácil pegar o Class dele:
Negociacao n = new Negociacao();
// chamamos o getClass de Object
Class<Negociacao> classe = n.getClass();

Mas nem mesmo precisamos de um objeto para conseguir as informações da sua classe. Diretamente com o
nome da classe também podemos fazer o seguinte:
Class<Negociacao> classe = Negociacao.class;

Capítulo 12 - API de Reflection - Constructor, Field e Method - Página 161


Java 5 e Generics
A partir do Java 5, a classe Class é tipada e recebe o tipo da classe que estamos trabalhando. Isso
melhora alguns métodos, que antes recebiam Object e agora trabalham com um tipo T qualquer,
parametrizado pela classe.
A partir de um Class podemos listar, por exemplo, os nomes e valores dos seus atributos:
for (Field atributo : classe.getDeclaredFields()) {
System.out.println(atributo.getName());
}

A saída será:
preco
quantidade
data

Fazendo similarmente para os métodos é possível conseguir a lista:
for (Method metodo : classe.getDeclaredMethods()) {
System.out.println(metodo.getName());
}

Cuja saída será:
getPreco
getQuantidade
getData
getVolume
isMesmoDia

Assim como podemos descobrir métodos e atributos, o mesmo aplica para construtores. Para, por exemplo,
descobrir o construtor da classe MediaMovelSimples:
Class<MediaMovelSimples> classe = MediaMovelSimples.class;
Constructor<?>[] construtores = classe.getConstructors();
for (Constructor<?> constructor : construtores) {
System.out.println(Arrays.toString(constructor.getParameterTypes()));
}
Capítulo 12 - API de Reflection - Constructor, Field e Method - Página 162


Imprime o tipo do parâmetro do único construtor:
interface br.com.caelum.argentum.indicadores.Indicador

É possível fazer muito mais. Investigue a API de reflection usando ctrl + espaço a partir das classes Method,
Constructor e Fields no Eclipse e pelo JavaDoc.

Usando anotações

Anotações (annotations) são uma novidade do Java 5 cujo objetivo é possibilitar a declaração de
metadados nos nossos objetos, isto é, configurações de uma classe podem ficar dentro dela, em
vez de em um XML à parte.
Até agora, usamos anotações para indicar que um método já foi sobrescrito (@Override) e para
configurar um método como teste do JUnit (@Test) e talvez, tenhamos visto outras anotações
como a (@Deprecated) que indica que um método não deve ser utilizado.
Em todas essas ocasiões, percebemos que a presença da anotação não influi no comportamento
daquela classe, daqueles objetos. Não são códigos executáveis, que mudam o que é executado ou
não. São metadados, informações (dados), que falam sobre nossa classe mas não fazem parte da
classe em si.
Metadados são muito usados para configurações de funcionalidades anexas àquela classe. Por
exemplo, usamos a anotação do Test para configurar que o JUnit entenda aquele método como
um teste e execute-o quando a classe for executada. Mas, se retirarmos a anotação, a nossa classe
continua compilando normalmente - apenas, quando rodarmos o JUnit, esse método será ignorado.
Em geral usamos anotações para criar configurações nos nossos artefatos com objetivo de que
depois essas anotações sejam lidas e processadas por alguém interessado naquelas informações.

12.5

Melhorando nosso ArgentumBean

Já temos os conhecimentos necessários para melhorar nosso método preparaDados(). A primeira necessidade naquele método é instanciar um Indicador a partir da String recebida. Mas antes é preciso descobrir a
classe pela String e através do método newInstance() instanciar um objeto da classe.

{

....

Capítulo 12 - API de Reflection - Melhorando nosso ArgentumBean - Página 163


GeradorModeloGrafico gerador = new GeradorModeloGrafico(serie, 2,
serie.getTotal() -1 );
Indicador indicador = (Indicador) Class.forName(
"br.com.caelum.argentum.indicadores." + this.nomeIndicador)
.newInstance();
gerador.plotaIndicador(montador.getIndicador());
...
}

Se a média for passada precisamos criá-la a partir da String. Diferente das classes indicadoras as médias, que
também são indicadores mas com foco em cálculos matemáticos, recebem um indicador via construtor. E
por isso não basta fazer a chamada ao método newInstance(), já que este só consegue instanciar quando
existe o construtor sem argumentos ou o padrão.
Por outro lado, já sabemos como descobrir o construtor a partir de um Class. A boa notícia é que existe
como criarmos uma instância a partir de um Constructor, pelo mesmo método newInstance() que passa a
receber parâmetros.
Veja o código:

{

....
.newInstance();
if(!this.nomeMedia.isEmpty()) {
Constructor<?> constructor = Class.forName(
"br.com.caelum.argentum.indicadores". + this.nomeMedia)
.getConstructor(Indicador.class);
indicador = (Indicador) constructor.newInstance(indicador);
}
...
}

Repare que esse código funciona com qualquer indicador ou média. Desde que seguimos da convenção de
usar o nome da classe no combo box como parâmetro, não terá nenhum problema com esse trecho.
No outro lado perceba que o código expõe muitos detalhes. Para entender o que ele realmente faz, é preciso
conhecer a API de Reflection. Vamos criar uma classe que se preocupa como montar um indicador e esconder
esses detalhes. Seguiremos boas práticas do paradigma Orientado a Objetos, igual ao que já fizemos com as
classes ClienteWebService e GeradorModeloGrafico.


A nova classe se chamará MontadorIndicador. Ela recebe o nome do indicador e da média no construtor e
devolve um indicador pronto para usar. Um esboço dessa classe:
public class MontadorIndicador {
public MontadorIndicador(String nomeIndicador, String nomeMedia) {
this.nomeIndicador = nomeIndicador;
this.nomeMedia = nomeMedia;
}
public Indicador getIndicador() {
//Aqui vem todo o código de reflection
}
}

Além dos dois atributos vamos criar uma constante para o nome do package. Estamos usando o mesmo
pacote para o indicador e a média, uma boa causa para definir o constante:
public class MontadorIndicador {
private static final String PACKAGE = "br.com.caelum.argentum.indicadores.";
//atributos e construtor omitidos
Indicador indicador = (Indicador) Class.forName(PACKAGE + this.nomeIndicador)
.newInstance();
if(this.nomeMedia != null && !this.nomeMedia.isEmpty()) {
Constructor<?> constructor = Class.forName(PACKAGE + this.nomeMedia)
}
return indicador;
}
}

Por fim falta o tratamento de exceções. A API de reflection é infelizmente cheio de exceções do tipo checked
que o compilador nos obriga a tratar. Nesse pequeno trecho de código serão lançadas nada mais do que 5
exceções checked. Podemos dar um throws na assinatura do método, mas isso violaria o encapsulamento
pois iria expor detalhes da implementação.


O mais aconselhado então seria capturar cada exceção e relançá-la através de uma exceção unchecked:
try {
Indicador indicador = (Indicador) Class.forName(PACKAGE + this.nomeIndicador)
.newInstance();
if(this.nomeMedia != null && !this.nomeMedia.isEmpty()) {
Constructor<?> constructor = Class.forName(PACKAGE + this.nomeMedia)
}
return indicador;
} catch (InstantiationException e)
} catch (IllegalAccessException e)
} catch (ClassNotFoundException e)
} catch (NoSuchMethodException e)
} catch (InvocationTargetException
}

{
{
{
{
e) {

}

Voltando à classe ArgentumBean vamos então delegar a criação do indicador para o montador:
....
MontadorIndicador montador =
new MontadorIndicador(this.nomeIndicador, this.nomeMedia)
Indicador indicador = montador.getIndicador();
...
}

Dessa forma as responsabilidades estão bem definidas e a evolução do sistema não depende de mais ifs no
nosso preparaDados().



Repare que hoje o MontadorIndicador é uma fábrica de indicadores, sendo assim vamos usar a mesma estratégia do CandlestickFactory e renomeá-lo para IndicadorFactory. Com o recurso de refactoring essa
mudança é simples e eficiente já que altera todos os outros pontos do sistema.

12.6

Exercícios: Plotando indicadores

1) Crie a classe usando ctrl + N Class, chamada IndicadorFactory no source folder src/main/java e dentro
do pacote br.com.caelum.argentum.indicadores
2) Declare na classe gerada os atributos: nomeIndicador e nomeMedia.
public class IndicadorFactory {
}

3) O próximo passo é declarar o construtor que receba os nossos atributos. Para isso vamos usar mais uma
das facilidades do Eclipse. Dentro da classe Indicador Factory use alt + shift + S e selecione Generate
Constructor Using Fields.

Selecione todos os atributos e aperte em ok.

Capítulo 12 - API de Reflection - Exercícios: Plotando indicadores - Página 167


Sua classe deve estar como o código a seguir:
public class IndicadorFactory {
public IndicadorFactory(String nomeIndicador, String nomeMedia) {
this.nomeIndicador = nomeIndicador;
this.nomeMedia = nomeMedia;
}
}

4) Como nosso objetivo é devolver um Indicador nessa Factory, crie o método getIndicador() que deve
devolver um Indicador. E ele deve ter a seguinte implementação:
try {



.newInstance();
if (this.nomeMedia != null && !this.nomeMedia.isEmpty()) {
Constructor<?> constructor = Class.forName(
"br.com.caelum.argentum.indicadores." + this.nomeMedia)
}
return indicador;
} catch (Exception e) {
}
}

5) Repare que repetimos a String com o nome do pacote, br.com.caelum.argentum.indicadores., em dois
lugares do método. Caso esse pacote seja renomeado, esses dois pontos devem ser modificados. Logo, vamos declarar uma constante para esse pacote e evitar duplicações. Mais uma vez vamos utilizar o recurso
de refactoring da IDE.
Selecione a String, "br.com.caelum.argentum.indicadores.", botão direito e Refactor. Dentro desse
opção, selecione Extract Constant ....

Declare no campo Constant name o valor de PACKAGE.


6) Com o IndicadorFactory criado, vamos usá-lo no método preparaDados() da classe ArgentumBean.
Abra a classe e faça o gerador GeradorModeloGrafivo usar o IndicadorFactory como segue:
...
new GeradorModeloGrafico(serie, 2, serie.getTotal() -1 );
IndicadorFactory indicadorFactory =
new IndicadorFactory(getNomeIndicador(), getNomeMedia());
gerador.plotaIndicador(indicadorFactory.getIndicador());
}

7) (opcional) Vamos criar um teste para nosso IndicadorFactory.
Crie uma classe de
teste, chamada IndicadorFactoryTest no source folder src/test/java e dentro do pacote
br.com.caelum.argentum.indicadores. Pelo menos dois testes são necessário: um quando é um
indicador simples e outro quando está associado as médias.
public class IndicadorFactoryTest {
@Test


public void testMontaAbertura() {
String nomeIndicador = "IndicadorAbertura";
new IndicadorFactory(nomeIndicador, null);
Indicador indicador = indicadorFactory.getIndicador();
Assert.assertTrue(indicador instanceof IndicadorAbertura);
}
@Test
public void testMontaAberturaComMediaMovelSimples() {
String nomeIndicador = "IndicadorAbertura";
String nomeMedia = "MediaMovelSimples";
new IndicadorFactory(nomeIndicador, nomeMedia);
Indicador indicador = indicadorFactory.getIndicador();
Assert.assertTrue(indicador instanceof MediaMovelSimples);
}
}


Capítulo 13

Apêndice Testes de interface com Selenium
“Além da magia negra, há apenas automação e mecanização”
– Federico Garcia Lorca

13.1

Introdução ao teste de aceitação

Nos capítulos anteriores fizemos uso dos testes de unidade, será que eles são suficientes para garantir que
a aplicação funcione da maneira esperada? Em um projeto web, uma das partes mais importantes para o
funcionamento desejado é a parte de apresentação, já que é a partir dela que toda a comunicação do cliente
com o nosso sistema será feita.
Verificar se as funcionalidades de um sistema estão se comportando corretamente sem que tenhamos de
testar manualmente a aplicação, abrindo um navegador, navegando por ele e visualizando os resultados são
tarefas que são realizadas pelos Acceptance Testing (ou Testes de Aceitação).
Temos que testar o nosso código, mas em uma aplicação web fica difícil testar a camada de apresentação,
o resultado final. Como testar a compatibilidade entre browsers diferentes de maneira automatizada? Em
geral, como testar se a página renderizada tem o resultado desejado?
Para isso ser possível, existem algumas ferramentas que permitem tal trabalho, simulando a interação de um
usuário com a aplicação. Esse é o caso do Selenium que, com a assistência do JUnit, pode facilitar o trabalho
de escrever tais testes.

13.2

Como funciona?

Para demonstrar como o Selenium funciona, testaremos se a validação do campo titulo funciona corretamente, isto é, o formulário não poderá ser submetido caso ele esteja em branco.


A primeira coisa que uma pessoa faz para testar a aplicação é abrir um browser. Com Selenium, precisamos
apenas da linha abaixo:
WebDriver driver = new FirefoxDriver();

Nesse caso, abrimos o Firefox. A ideia aqui é igual ao mundo JDBC onde o Driver abstrai detalhes sobre o
funcionamento do banco de dados. Em nosso caso o driver se preocupa com a comunicação com o navegador.
Há outros drivers disponíveis para Chrome, Internet Explorer, Safari e até para Android ou iPhone. O que
precisa mudar é apenas a implementação concreta da interface WebDriver, por exemplo:
WebDriver driver = new InternetExplorerDriver();

HtmlUnitDriver
Há uma outra implementação do WebDriver disponível que nem precisa abrir um navegador.
Ela se chama HtmlUnitDriver e simula o navegador em memória. Isso é muito mais rápido mas
não testa a compatibilidade do navegador fidedignamente:
WebDriver driver = new HtmlUnitDriver();

Essa alternativa é bastante utilizada em ambientes de integração que fazem uso de um cloud, já
que não temos disponíveis um browser para teste.
O próximo passo é indicar qual página queremos abrir através do navegador. O driver possui um método
get que recebe a URL:
driver.get("http://localhost:8080/fj22-argentum-web/index.xhtml");

Com a página aberta, faremos a inserção de um valor em branco no campo titulo. Para isso, precisamos da
referência deste elemento em nosso código, o que é feito pelo método findElement.
Este método recebe como parâmetro um critério de busca. A classe By possui uma série de métodos estáticos.
Pesquisaremos pelo id:
WebElement titulo = driver.findElement(By.id("titulo"));
Capítulo 13 - Apêndice Testes de interface com Selenium - Como funciona? - Página 173


Agora que temos o elemento, podemos preenchê-lo com o texto que quisermos através do método sendKeys.
Em nosso caso, deixaremos o campo em branco passando uma string vazia:
titulo.sendKeys("");

Quando o formulário for submetido e o campo titulo estiver em branco, esperamos que o sistema mostre
a mensagem Erro de Validação.
Antes de testarmos se tudo esta correto, precisamos submeter o formulário. O objeto WebElement possui o
método submit que faz exatamente isso:
titulo.submit();

Para termos certeza de que o sistema esta validando, pediremos ao Selenium que procure pelo texto “Erro
de Validação”. Primeiro, precisamos evocar o método getPageSource, que nos permite procurar por algo no
código da página, e logo em seguida o método contains, que retorna true ou false:
titulo.submit();
boolean existeMensagem = driver.getPageSource().contains("Erro de validação");

Por fim, após o formulário ter sido submetido, precisamos saber se tudo saiu conforme o planejado, o que
pode ser feito através do método estático assertTrue da classe Assert, que recebe como parâmetro um
boolean que indica a presença ou não do texto procurado pelo método contains:
Capítulo 13 - Apêndice Testes de interface com Selenium - Como funciona? - Página 174


titulo.submit();
Assert.assertTrue(existeMensagem);

Pronto, podemos verificar no próprio Eclipse se o teste passou se ele estiver verde. Se algo der errado, como
de costume, a cor vermelha será utilizada.
Podemos usar agora o método driver.close() para fechar a janela do navegador.
titulo.submit();
boolean existeMensagem = driver.getPageSource().contains("Erro de validação);
driver.close();

13.3

Trabalhando com diversos testes de aceitação

É comum termos dois ou mais testes de aceitação em nossa bateria de testes. Teríamos então que abrir uma
janela do navegador em cada método, e, após os testes, fechá-la. Com isso, estaríamos repetindo muito
código! O Selenium nos permite fazer isso de uma forma mais fácil. Primeiro, criaremos o método setUp, e
o anotaremos com @Before.
@Before
public void setUp() {
driver = new FirefoxDriver();
}
Capítulo 13 - Apêndice Testes de interface com Selenium - Trabalhando com diversos testes de aceitação - Página 175


Este método será invocado antes de cada teste, sempre abrindo uma nova janela. Analogamente, existe a
anotação @After, que indica que o método será invocado após cada teste. Agora, precisamos fechar essas
janelas:
@After
public void tearDown() {
driver.close();
}

13.4

Para saber mais: Configurando o Selenium em casa

Caso você esteja fazendo esse passo de casa, é preciso baixar algumas JARs para o funcionamento dessa
aplicação, usaremos as seguintes versões:
• commons-exec-1.1.jar
• commons-logging-1.1.1.jar
• guava-14.0.jar
• httpclient-4.2.1.jar
• httpcore-4.2.1.jar
• json-20080701.jar
• selenium-java-2.31.0.jar
Para mais informações, você pode consultar o site http://docs.seleniumhq.org/

13.5

Exercícios: Teste com Selenium

Vamos criar nosso primeiro teste com Selenium:
1) Antes de tudo vamos colocar as jars do Selenium no nosso projeto, elas se encontram na pasta
Desktop/caelum/22/selenium-jars/:

Capítulo 13 - Apêndice Testes de interface com Selenium - Para saber mais: Configurando o Selenium em casa - Página 176


Para adicioná-las ao projeto, crie uma nova pasta chamada lib-teste na raiz do projeto e copie as jars
para dentro dela.

Logo em seguida adicione-as ao Build Path:

Capítulo 13 - Apêndice Testes de interface com Selenium - Exercícios: Teste com Selenium - Página 177


2) Crie a classe usando ctrl + N Class, chamada GeraGraficoTest no source folder src/test/java e dentro do
pacote br.com.caelum.argentum.aceitacao:
3) A classe terá dois atributos. O primeiro com a URL da página que queremos testar e o segundo o WebDriver, o objeto que nos permite manipular o navegador.
public class GeraGraficoTest {
private static final String URL =
"http://localhost:8080/fj22-argentum-web/index.xhtml";
private WebDriver driver;
}

4) Vamos criar o método testeAoGerarGraficoSemTituloUmaMensagemEhApresentada e anotá-lo com
@Test para indicar que ele deve ser chamado quando o teste for executado:
@Test
public void testeAoGerarGraficoSemTituloUmaMensagemEhApresentada() {
}
}

5) Usaremos o WebDriver para abrir uma nova janela do Firefox e acessar a URL do projeto, e usaremos o
método driver.close() para fechar a janela



@Test
driver.get(URL);
driver.close();
}
}

6) Estamos testando se a mensagem de erro aparece quando submetemos um formulário com o título. Para
isso, primeiro precisamos capturar o elemento do título em um WebElement. Como estamos trabalhando
com JSF, devemos lembrar que ele concatena o id do formulário com o id dos inputs. Por conseguinte,
devemos procurar o elemento pelo id dadosGrafico:titulo
@Test
driver.get(URL);
WebElement titulo = driver.findElement(By.id("dadosGrafico:titulo"));
titulo.submit();
driver.close();
}
}

7) Vemos que usamos driver = new FirefoxDriver() para abrir uma janela (um WebDriver) do navegador, e driver.close() para fechar a janela. Caso formos escrever mais testes, precisaremos abrir e fechar
o navegador novamente. Para podermos reaproveitar esse código, podemos colocá-los em blocos sepaCapítulo 13 - Apêndice Testes de interface com Selenium - Exercícios: Teste com Selenium - Página 179


rados e usar as anotações @Before, para executá-lo antes de cada método, e @After, para executá-lo após
cada método.
@Before
public void setUp() {
}
@After
public void tearDown() {
driver.close();
}
@Test
driver.get(URL);
WebElement titulo = driver.findElement(By.id("dadosGrafico:titulo"));
titulo.submit();
}
}


Índice Remissivo
Anotações, 163
anotações, 35
Calendar, 12
Candlestick, 5, 8
datas, 12
Design patterns, 139
Factory pattern, 13
final, 9
JUnit, 34
Negociação, 8
Reflection, 161
static import, 49
Tail, 6
TDD, 64
Test driven design, 64
testes de unidade, 33
testes unitários, 33

181

Caelum java-testes-jsf-web-services-design-patterns-fj22

Mais conteúdo relacionado

Mais procurados (15)

Semelhante a Caelum java-testes-jsf-web-services-design-patterns-fj22 (20)

Mais de Lindomar ... (20)

Caelum java-testes-jsf-web-services-design-patterns-fj22