Apostila de Java e Orientação a Objetos revisada e ampliada

FJ-11
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.

27 Comentários

  1. Marcio 13/03/2008 at 02:57 #

    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!

  2. Gerson K. Motoyama 13/03/2008 at 03:28 #

    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:

    The API is primarily designed to be readable and to flow.

    The key test of fluency, for us, is the Domain Specific Language quality. The more the use of the API has that language like flow, the more fluent it is.

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

  3. Sérgio Lopes 13/03/2008 at 05:30 #

    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.

  4. Paulo Silveira 13/03/2008 at 11:09 #

    Oi Gerson. A nome dos métodos realmente poderia ser muito melhor como Sergio falou agora… até acho que seria melhor comLargura do que apenas largura, o que acha? Também prefiro que o nome da classe seja apenas Grafico.

    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.

  5. BRian Aluizio Carneiro de Lima 13/03/2008 at 12:38 #

    Como faço para adquiriu ou baixar uma apostila sobre Netbenas??

    Desde ja agradeço

  6. Sérgio Lopes 13/03/2008 at 13:31 #

    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)

  7. Gerson K. Motoyama 13/03/2008 at 13:43 #

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

  8. Maciel Rodrigues de Jesus 13/03/2008 at 14:19 #

    Em minha primeira visita a este site gostei muito!!

  9. Paulo Silveira 13/03/2008 at 15:32 #

    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.

  10. José Mauro de Barros 30/03/2008 at 20:01 #

    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.

  11. Leonardo 02/04/2008 at 12:45 #

    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

  12. Sérgio Lopes 02/04/2008 at 12:50 #

    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

  13. Fabio Kung 02/04/2008 at 14:03 #

    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

  14. Aguida 07/04/2008 at 03:25 #

    Esse material está otimo pra quem vai iniciar os estudos a linguagem Java!!

  15. Giovanny Lima 08/04/2008 at 22:03 #

    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

  16. Paulo Silveira 08/04/2008 at 22:54 #

    Obrigado Ritchie! So falta o Kernighan comentar!!! 🙂

  17. Gerson 26/04/2008 at 18:48 #

    O arquivo está danificado !!!

  18. Paulo Silveira 26/04/2008 at 19:39 #

    Gerson, basta atualizar o seu Acrobat Reader!

  19. Gerson 26/04/2008 at 21:07 #

    isso mesmo, obrigado Paulo.

  20. Edward 28/04/2008 at 17:07 #

    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???/

  21. Sérgio Lopes 28/04/2008 at 19:44 #

    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

  22. Edward 29/04/2008 at 01:41 #

    Muito obrigado Sérgio….

  23. RICELLI 12/05/2008 at 17:33 #

    Eu não consigo baixar a apostila, pois a página nunca abre.

  24. Eduardo Gomes da Silva 16/05/2008 at 14:17 #

    Parabéns, apostila que vcs apresentaram e excelente para o aprendizado estou aprendendo muito com ela.

  25. Agostinho Rogerio gentine 13/07/2008 at 19:38 #

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

  26. Ednaldo 30/05/2009 at 10:45 #

    Preciso só de uma apostila boa pra poder começar. E aí, é possível?

  27. Sérgio Lopes 01/06/2009 at 01:37 #

    Oi Ednaldo!

    A apostila do FJ-11 é excelente para isso!

    []’s
    Sérgio Lopes

Deixe uma resposta