caelum - java - testes - xml - design - patterns - fj16, Notas de estudo de Informática

Baixe caelum - java - testes - xml - design - patterns - fj16 e outras Notas de estudo em PDF para Informática, somente na Docsity!

FJ-

Laboratório Java com Testes,

XML e Design Patterns

A Caelum atua no mercado com consultoria, desenvolvimento e ensino em computação. Sua equipe participou do desenvolvimento de projetos em vários clientes e, após apresentar os cursos de verão de Java na Universidade de São Paulo, passou a oferecer treinamentos para o mercado. Toda a equipe tem uma forte presença na comunidade através de eventos, artigos em diversas revistas, participação em muitos projetos open source como o VRaptor e o Stella e atuação nos fóruns e listas de discussão como o GUJ.

Com uma equipe de mais de 60 profissionais altamente qualificados e de destaque do mercado, oferece treinamentos em Java, Ruby on Rails e Scrum em suas três unidades - São Paulo, Rio de Janeiro e Brasília. Mais de 8 mil alunos já buscaram qualificação nos treinamentos da Caelum tanto em nas unidades como nas próprias empresas com os cursos incompany.

O compromisso da Caelum é oferecer um treinamento de qualidade, com material constantemente atualizado, uma metodologia de ensino cuidadosamente desenvolvida e instrutores capacitados tecnicamente e didaticamente. E oferecer ainda serviços de consultoria ágil, mentoring e desenvolvimento de projetos sob medida para empresas.

Comunidade

Nossa equipe escreve constantemente artigos no Blog da Caelum que já conta

com 150 artigos sobre vários assuntos de Java, Rails e computação em geral.

Visite-nos e assine nosso RSS:

➡ blog.caelum.com.br

Acompanhe também a equipe Caelum no Twitter :

➡ twitter.com/caelumdev/equipe

O GUJ é maior fórum de Java em língua portuguesa, com 700 mil posts e 70 mil

usuários. As pessoas da Caelum participam ativamente, participe também:

➡ www.guj.com.br

Assine também nossa Newsletter para receber as novidades e destaques dos

eventos, artigos e promoções da Caelum:

➡ www.caelum.com.br/newsletter

No site da Caelum há algumas de nossas Apostilas disponíveis gratuitamente

para download e alguns dos artigos de destaque que escrevemos:

➡ www.caelum.com.br/apostilas

➡ www.caelum.com.br/artigos

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, XML 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

Índice

CAPÍTULO 1

Tornando-se um desenvolvedor pragmático

“Na maioria dos casos, as pessoas, inclusive os fascínoras, são muito mais ingênuas e simples do que costumamos achar. Aliás, nós também.”

• Fiodór Dostoievski, em Irmãos Karamazov

Porque 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 expe- riê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 unitários (conhecido também como testes de unidade) 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/

Somamos a esses mais dois livros, que serão citados no decorrer do curso, e influenciaram muito na elabo- raçã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 do atual líder do projeto Eclipse na IBM, Erich Gamma, 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

1

Material do Treinamento Laboratório Java com Testes, XML e Design Patterns

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.

1.3 - Tirando dúvidas

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.

1.4 - Mais bibliografia

Além dos livros já citados, podemos incluir:

• Test Driven Development: By Example , Kent Beck.
• Domain Driven Design , Eric Evans.
• Swing Second Edition , Matthew Robinson e Pavel Vorobiev, editora Manning;
• Tutorial oficial de Swing , em http://java.sun.com/docs/books/tutorial/uiswing/.

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

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-16 é aprender boas práticas da orientação a objetos, do design de classes, uso correto dos design patterns, métodos ágeis de programação e a importância dos testes unitários. 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 exaus- tivamente em filmes, livros e em toda a cultura contemporânea. Somente em novembro de 2007, o total movi- mentado pela BOVESPA foi de R$ 128,7 bilhões. Destes, o volume movimentado por aplicacões home broker foi de R$ 22,2 bilhões.

Neste curso, abordaremos esse assunto tão atual 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, dada 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 mesmo Yodoya Keian, que nasceu a bolsa de arroz do Japão. Lá eram negociados vários tipos de arroz, e também eram precificados e categorizados.

Para anotar os preços do arroz desenhavam-se figuras no papel. Essas figuras parecem muito como velas (daí a analogia candlestick , um candelabro, gráfico que carrega várias velas, ou candles ).

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

4

Material do Treinamento Laboratório Java com Testes, XML e Design Patterns

O preço de abertura e fechamento depende 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 branco, e um de baixa costuma ser vermelho ou preto. Caso o preço não tenha se movimentado, o candle tem a mesma cor que o do dia anterior.

Para calcular as informações necessárias para a construção de um candlestick, é necessário os dados de todos os negócios (trades) de um dia. Um negócio possui três informações: o preço em que foi fechado, a quantidade negociada, e a data que foi executado.

Você pode ler mais sobre a história dos candles em: http://www.candlestickforum.com/PPF/Parameters/

1_279_/candlestick.asp http://www.thepitmaster.com/tricks/japanesecandlesticks.htm

Uma outra forma de representar os candles mais sucintamente é através de barras, que são análogas:

Apesar de falarmos que o candlestick representa o preço 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 idéia do projeto Tail ( T echnical A nalysis I ndicator L ibrary) nasceu quando um grupo de alunos da Univer- sidade de São Paulo procurou o professor doutor Alfredo Goldman para orientá-los no desenvolvimento de um

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

Material do Treinamento Laboratório Java com Testes, XML e Design Patterns

• 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 co-orientação, com o objetivo estendê-lo para projetos futuros.

O Tail foi desenvolvido por Alexandre Oki Takinami, Carlos Eduardo Manssuer, Márcio Vinicius dos Santos, Thiago Garutti Thies, Paulo Silveira (mestre em Geometria Computacional pela USP, e diretor de treinamentos da Caelum), Julian Monteiro (mestre em sistemas distribuídos pela USP e doutorando no INRIA, em Sophia Antipolis, na França) e Danilo Sato (mestre em Metodologias Ágeis pela USP, e desenvolvedor da ThoughtWorks em Londres).

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:

[email protected]:/cvsroot/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, e por isso usamos algo similar a ele como base para este treinamento FJ-16.

Queremos modelar diversos objetos do nosso sistema, entre eles teremos:

• Negocio - 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 entidades formarão a base do projeto que criaremos durante o treinamento, o Argentum (do latim, dinheiro ou prata). As funcionalidades do sistema serão os seguintes:

• Converter Negocios em Candlesticks. Nossa base serão os Negócios. Precisamos converter uma lista de negócios em uma lista de Candles.
• Converter Candlesticks em SerieTemporal. Dada uma lista de Candle, precisamos fabricar uma série temporal.
• Funcionalidades na SerieTemporal Buscar candles por data, intervalos e outros

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

Material do Treinamento Laboratório Java com Testes, XML e Design Patterns

• Utilizar indicadores técnicos Para isso implementar um pequeno framework de indicadores, e criar alguns deles, facilitando o desen- volvimento de novos.
• Gerar gráficos Tanto dos candles, quanto dos indicadores.

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.

2.5 - 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 Negocio, não queremos que seu valor seja modificado:

class Negocio {

private final double valor;

// getters e setters?

}

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 do Negocio na declaração da variável (que não faz muito sentido nesse caso) ou então populamos pelo construtor:

class Negocio {

private final double valor;

public Negocio(double valor) { this.valor = valor; }

// podemos ter um getter, mas nao um setter aqui!

}

Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Palavra chave final - Página 8

Material do Treinamento Laboratório Java com Testes, XML e Design Patterns

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 ocorrer duas modificações concorrentes!

Objetos mais simples

Uma classe imutável é mais simples de dar manutenção. Como não há chances de seu objeto ser modifi- cado, 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á preo- cupaçã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.

Nossa classe Negocio sendo imutável simplifica muitas dúvidas e medos que poderíamos ter durante o desenvolvimento do nosso projeto: saberemos em todos os pontos que os valores do negócio são sempre os mesmos, não correndo o risco que um método que constrói o candlestick mexa nos nossos atributos (deixando ou não num estando inconsistente), além de garantir que não haverá problemas no caso de acesso concorrente ao objeto.

2.7 - Trabalhando com datas: Date e Calendar

A classe abstrata Calendar encapsula um instante, em milissegundos. Também provê métodos para mani- pulação desse instante.

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 internas 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.

Calendar agora = Calendar.getInstance();

Porque não damos new diretamente em GregorianCalendar? A API da Sun 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 mudam. 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: Consider static factory methods instead of constructors

Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Trabalhando com datas: Date e Calendar - Página 10

Material do Treinamento Laboratório Java com Testes, XML e Design Patterns

Repare ainda que há um overload desse método que recebe Locale ou Timezone como argumento, caso você queira que essa factory trabalhe sem ser de acordo com os valores defaults que a JVM descobrir em rela- ção ao seu ambiente. Um 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... 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: 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:

Calendar c = Calendar.getInstance(); c.set(Calendar.HOUR, 10); // fazemos hora valer 10 c.set(Calendar.MINUTE, 30); // fazemos minuto valer 30 c.set(2005, 11, 25); // mudamos a data para o Nata, mês começa do 0

Outro método bastante usado é add, que adiciona uma certa quantidade a qualquer campo do Calendar. Por exemplo, para adicionar um ano à data de hoje:

Calendar c = Calendar.getInstance(); 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 Calendar em questão estiver num momento no tempo maior que o 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:

Capítulo 2 - O modelo da bolsa de valores, datas e objetos imutáveis - Trabalhando com datas: Date e Calendar - Página 11