Apostila de Java e Orientação a Objetos revisada e ampliada
Por Sérgio Lopes em 12/03/08
Em nossa constante política de manter nossas apostilas atualizadas, estamos disponibilizando hoje a última versão do FJ-11: Java e Orientação a Objetos. Foram várias correções de bugs, atualizações e melhorias no texto (algumas seções foram inclusives reescritas).
Essa apostila já vinha sendo usada aqui na Caelum nos nossos treinamentos há alguns meses. Nesse período, aproveitamos para corrigir bugs e finalizar o material. Entre as novidades, estão algumas discusões sobre design patterns ao longo do curso, atualização para Java 6, novos assuntos (como fluent interfaces) e mais texto. Os capítulos de Threads e Sockets foram reescritos e ampliados. Há também um novo capítulo sobre JARs e bibliotecas, que mostra a famosa ferramenta JFreeChart para desenvolvimento de gráficos em Java.
Muitos exercícios foram reelaborados e estendidos, além de alguns novos que foram incluídos. Há também muitos links para outros materiais, como artigos do nosso blog e outras referências ao longo do texto.
Além disso, a partir dessa versão, estamos usando o Latex (do Donald Knuth) para escrever a apostila e conseguir um resultado final graficamente mais profissional. Aliás já usamos também na apostila de Estruturas de Dados e Algoritmos em Java e logo também nas outras apostilas. (criamos um projeto para ajudar na escrita do latex e gerenciamento das apostilas; mais detalhes em breve)
Acesse a nova versão da apostila na página do treinamento FJ-11. Ou entre em contato conosco para mais informações sobre o treinamento.
Olá, eu tentei baixar o pdf da apostila revisada do FJ-11 e na hora de abrir acusa erro de não poder abrir por estar danificado!
Mas é isso ai, boa iniciativa da caelum disponibilizando as apostilas pra comunidade e ainda por cima revisando… estão de parabéns!!
obrigado!
Comment by Marcio — March 13, 2008 @ 2:57 am
Olá, tenho algumas críticas.
Lí a apostila especificamente na parte sobre Fluent Interface, e devo dizer que quem escreveu sobre este assunto realmente não entendeu o que o Fowler e o Eric quiseram dizer com ‘interface fluente’.
Simplesmente fazer chamadas encadeadas de métodos não torna uma interface fluente. O Criteria API do Hibernate, como o Philip Calçado diz, como a apostila citou, não passa de um Syntatic Sugar. A fluência que eles tanto dizem está relacionada com DSL (Domain Specific Language)!
Veja o que o Fowler diz no Bliki:
Em relação ao exemplo da apostila que usa uma classe imaginária ‘ChartBuilder’, achei, no mínimo, esquisito. Primeiro de tudo, esse ‘ChartBuilder’ é o que? Um Builder Pattern (GoF)? Bom, imagino que não, já que seria estranho ter um método salvar() nele. E o método criaGrafico(), o que ele tá fazendo alí? Cadê o mínimo de coesão? Outra coisa, na maioria das vezes (e, no meu caso, sempre), utiliza-se APIs fluentes para configurar objeto (segundo o Fowler/Eric Evans, na maioria das vezes, value objects)… e não fazer o que o exemplo está tentando fazer (seja lá o que ele estiver tentando fazer).
Para referência, estou colando o código exemplo da apostila que diz usar fluent interface:
new ChartBuilder(mapa)
.criaGrafico("Meu Grafico")
.setTamanho(600, 420)
.salvar(new FileOutputStream("grafico.png"));
Comment by Gerson K. Motoyama — March 13, 2008 @ 3:28 am
Oi Gerson!
Realmente o exemplo de Fluent Interfaces poderia ter sido mais feliz (acabou sendo um exemplo de chainning methods). Talvez algo assim fosse mais interessante:
new Grafico()
.dados(mapa)
.titulo("Meu Grafico")
.largura(600)
.altura(420)
.salvar(new FileOutputStream("grafico.png"));
(aquele setter estava realmente bizarro)
Sobre o Builder ter um salvar() não vejo grandes problemas. Claro que normalmente o uso do Builder é pra criar objetos complexos (e não arquivos etc), mas não vejo muito problema nisso.
Comment by Sérgio Lopes — March 13, 2008 @ 5:30 am
Oi Gerson. A nome dos métodos realmente poderia ser muito melhor como Sergio falou agora… até acho que seria melhor
comLargurado que apenaslargura, o que acha? Também prefiro que o nome da classe seja apenasGrafico.Não vejo problemas no método salvar e não entendi porque você o achou estranho. Muitas fluent interface possuem um “último” método que termina a sentença, não que seja obrigatório.
Sobre usar fluent interface para configurações, o Fowler diz que é o que ele estava acostumado a ver, e não que isso deveria ser regra, correto?
sobre a Criteria ser fluent interface ou não, creio isso ser subjetivo: para voce o criteria não é bem mais facil de ler e as vezes até obvio? Ja usou Criteria fazendo imports estáticos, para não ter de escrever Order, Restrictions e outros, deixando a mensagem super enxuta? Exemplo digitado da cabeça:
List resultado = criteria.add(or(equals(”nome”, nome), gt(”idade”, 18)).list(); O que acha? Muito próximo ao que o Phillip colocou como uma alternativa melhor ao Criteria geral, da até para chegar no que ele sugeriu se você adicionar alguns métodos estáticos a sua classe (hum…). Muito próximo também ao JMock, que todos consideram uma das mais bontias implementações de fluent interface.
Obrigado pela mensagem tão detalhada.
Comment by Paulo Silveira — March 13, 2008 @ 11:09 am
Como faço para adquiriu ou baixar uma apostila sobre Netbenas??
Desde ja agradeço
Comment by BRian Aluizio Carneiro de Lima — March 13, 2008 @ 12:38 pm
Eu pensei tbm no comLargura, mas engraçado que tenho uma barreira com esse negocio de “com” (with) hehehe
Toda bendita DSL que se ve por aí tem um bendito metodo “with”! (e nunca gostei disso)
Mas realmente pode ser mais legível (comTitulo, comLargura, comAltura)
Comment by Sérgio Lopes — March 13, 2008 @ 1:31 pm
Sérgio/Paulo,
Sim, o exemplo ficou melhor, mas, ainda assim, eu colocaria algo como:
/* Cria configuração da instância de Gráfico usando Fluent Interface */
Grafico grafico =
criarGrafico()
.comTitulo("Meu Grafico")
.comLargura(100)
.comAltura(200)
...
;
/* Executa alguma operação sobre o objeto configurado */
grafico.salvar();
Lendo o código, ficaria assim:
- criarGrafico com Titulo “Meu Grafico”, com Largura 100, com Altura 200. Salvar (o gráfico).
Observem que criarGrafico() é um static factory method de uma classe que foi omitida com a ajuda de static import (Java 5+).
Realmente, como vocês disseram, não existe (pelo menos eu não encontrei) um critério objetivo para considerar uma interface fluente ou não. No máximo que dá para tentar fazer é comparar entre duas implementações e dizer quem é mais fluente que o outro. Então, no caso do Criteria API do Hibernate, podemos acabar entrando numa discussão sem fim… Eu, particularmente, não acho o Criteria API fluente (pelo menos não fluente suficiente para eu dizer que é fluente =). Paulo, no seu exemplo de Criteria, embora eu concorde que facilite, particularmente, não acho a leitura tão trivial. Vou mostrar: “criteria add or equals ‘nome’ nome”, gt ‘idade’ 18, list”. Vocês conseguem entender isso? Eu não consigo enxergar fluência (em leitura) nisso. Agora, lendo o que o Philip colocou, experimente ler: “list Cat.class with ‘name’ like ‘Fritz%’ and with ‘weight’ between minWeight maxWeight” … viu a diferença?
Sobre usar Fluent Interface para configurações, como você disse Paulo (e eu também), não é uma regra… podiamos escrever algo como “levantar().lavarRosto().escovarDente().tomarCafe()”. Mas, para obter esse efeito, basicamente basta que os nomes dos métodos estejam no infinitivo (pode até ser “levanta”, “escova..”, etc.), que já é uma prática comum, e fazer method chaining (que é algo comum também)… ou seja, sendo assim, seguindo essa regra básica, qual é a novidade da Fluent Interface nisso? Por isso, principalmente para efeito didático, vejo sendo muito mais interessante colocar um exemplo de configuração de objeto, que, realmente explica esse estilo diferente.
Concordo que seja comum ter um método que termina a sentença. aliás, é comum quando a implementação usa ‘intermediate objects’, sendo que o último método, diferente de outros que retornam ‘objetos intermediários’, retorna a instância “real” (no caso do exemplo, a instância de Grafico). Mas quem deveria terminar a sentença é um método (ou, algumas vezes, ‘alguns métodos’) que configuram o objeto, e não o método que executa uma ação sobre o objeto configurado, como o salvar(..)!
Comment by Gerson K. Motoyama — March 13, 2008 @ 1:43 pm
Em minha primeira visita a este site gostei muito!!
Comment by Maciel Rodrigues de Jesus — March 13, 2008 @ 2:19 pm
Gerson, nao tenho como concordar mais. Parabens pelo argumento e pela argumentação. E aposto que na JPA 2 o Criteria deles sera bem parecido com esse codigo do Shoes.
Comment by Paulo Silveira — March 13, 2008 @ 3:32 pm
Estou iniciando os estudos em java e me interecei pela apostila
de java de voces , pois pelo indice me parece ser muito boa,
gostaria de utiliza-la.
josé Mauro de Barros.
Comment by José Mauro de Barros — March 30, 2008 @ 8:01 pm
Bom dia!!!
Estou estudando pelas apostilas da Caelum.
Como eu trabalho de segunda a sábado e resido no interior de Minas Gerais,aproximadamente 700 Km de São Paulo, fica inviável poder fazer qualquer curso na Caelum atualmente.
Gostaria de saber se é possível vocês me venderem ou disponibilizarem, as seguintes apostilas, impressas e encadernadas dos cursos:
FJ-31
FJ-55
FJ-28
FJ-26
FJ-21
FJ-19
FJ-11
Obrigado pela atenção,
Leonardo
Comment by Leonardo — April 2, 2008 @ 12:45 pm
Oi Leonardo!
Nós não vendemos apostilas a parte de cursos.
Porque você não entra em contato com nosso atendimento e vê a possibilidade de fazer alguns cursos conosco? Temos horarios e datas voltadas para pessoal que vem de longe como voce
Abraços
Sérgio
Comment by Sérgio Lopes — April 2, 2008 @ 12:50 pm
Leonardo, as apostilas do FJ-11, FJ-21 e FJ-28 estão disponíveis de graça lá no site da Caelum.
Já são um ótimo começo!
[]’s
Comment by Fabio Kung — April 2, 2008 @ 2:03 pm
Esse material está otimo pra quem vai iniciar os estudos a linguagem Java!!
Comment by Aguida — April 7, 2008 @ 3:25 am
Vocês sao muito bons. E é muito bom saber que existem pessoas disponibilizando os seus conhecimentos para o beneficio do mundo tecnologico…Continuem assim e espero que aumentem o numero de apostilas dispeniveis…Dennis Ritchie
Comment by Giovanny Lima — April 8, 2008 @ 10:03 pm
Obrigado Ritchie! So falta o Kernighan comentar!!!
Comment by Paulo Silveira — April 8, 2008 @ 10:54 pm
O arquivo está danificado !!!
Comment by Gerson — April 26, 2008 @ 6:48 pm
Gerson, basta atualizar o seu Acrobat Reader!
Comment by Paulo Silveira — April 26, 2008 @ 7:39 pm
isso mesmo, obrigado Paulo.
Comment by Gerson — April 26, 2008 @ 9:07 pm
Gostaria de saber se essa apostila Java para Web, vai desenvolvando um sistema para web no decorrer dela, passo a passo…. ou apenas vai explicando como funciona??
queria saber se no final da apostila vou ter um sistema web rodando com tomcat e etc???/
Comment by Edward — April 28, 2008 @ 5:07 pm
Oi Edward!
Na apostila de Java para Web, vamos desde banco de dados com JDBC, até Struts, passando por JSP e Servlets. No final, ha uma introducao a Hibernate e a VRaptor.
Ao longo do curso, voce desenvolve uma aplicacao completa mas fundamentada nos conceitos. Ha muitos exercicios praticos. Baixe a apostila e dê uma olhada!
[]’s
Comment by Sérgio Lopes — April 28, 2008 @ 7:44 pm
Muito obrigado Sérgio….
Comment by Edward — April 29, 2008 @ 1:41 am
Eu não consigo baixar a apostila, pois a página nunca abre.
Comment by RICELLI — May 12, 2008 @ 5:33 pm
Parabéns, apostila que vcs apresentaram e excelente para o aprendizado estou aprendendo muito com ela.
Comment by Eduardo Gomes da Silva — May 16, 2008 @ 2:17 pm
Estou interessado no curso de java.
Tenho 36 anos de experiência em programação. Várias linguagens de program~ção, incluindo Assembler 8080, 8085, z80, gp 16 (não existe mais) pdp11, Ibm 390, PIC (microcontroladr).
C, C++, COBOL, FORTRAN LPS (Linguagem de programação de Sistemas) ALGOL.
Conheço OOP por culpa do C++.
Comment by Agostinho Rogerio gentine — July 13, 2008 @ 7:38 pm