Ola pessoal,Segue abaixo os slides que utilizei para palestrar no The Developers Conference 2015 sobre Microservices com alguns frameworks em Java. Porem, contudo e entretanto, dediquei a palestra para compartilhar experiencias e dificuldades na migracao de uma arquitetura monolitica para uma arquitetura baseada em pequenos servicos. Desculpem-me os Javaneiros de plantao mas todos os nossos micro servicos escritos em Java foram reescritos em Golang. Em breve comecarei a compartilhar meu conhecimento sobre esta linguagem. Voce lembra quais as diferencas entre um JavaBean e um Pojo? Se sim, pule para o proximo paragrafo. Um JavaBean devem ter um construtor sem parametros, implementar java.io.Serializable, atributos privados e metodos assessores (seguindo a convencao, os get's e set's). E o Pojo? Qualquer outra classe Java diferente de uma classe JavaBean (qualquer coisa fique a vontade para discordar comentando no final da postagem). Uma vez que aprendemos a escrever um JavaBean, todos os nossos problemas estao resolvidos. Criamos nossos atributos privados com seus respectivos set's e esquecemos o conceito de Encapsulamento. Bom, deixaremos esta discussao para uma outra oportunidade, vamos quebrar um paradigma por vez.Para facilitar o entendimento, vamos comecar analisando o JavaBean abaixo:Como de costume, na maioria dos casos os desenvolvedores iniciam seus JavaBeans desta forma. Pois bem, pensando no ambito da aplicacao, como instanciaremos um objeto Pessoa? Facil! Ate aqui esta tudo certo, como tradicionalmente codificamos no nosso dia a dia. Agora vamos mudar um pouco, apresento-lhes uma outra forma de implementar o mesmo JavaBean Pessoa:Instanciaremos este novo JavaBean da seguinte forma. Voce consegue analisar tudo o que foi alterado e levantar as possiveis vantagens e desvantagens? Antes de prosseguir, pare por aqui durante poucos minutos e tente fazer uma auto-reflexao sobre estas alteracoes. Vou lhes ajudar em relacao as alteracoes: 1 - Alteramos o modificador de acesso do construtor do JavaBean Pessoa para default;2 - Criamos um metodo estatico para a fabricacao do nosso JavaBean.VantagensPensou bem? Encontrou alguma vantagem/desvantagem ou acha que apenas adicionamos complexidade ao codigo?Here we go!Primeira vantagem: Diferente dos construtores, os metodos tem nomes. Os metodos estaticos utilizados para as fabricacoes do nosso JavaBean Pessoa pode ter o nome que voce achar mais apropriado. Isto facilita quando disponibilizamos mais de um metodo de fabricacao com diferentes parametros. Do contrario, teriamos diversos construtores sobrecarregados. Segunda vantagem: Nao se faz necessario criar um novo objeto sempre que chamados o metodo estatico de fabricacao.Exatamente! Quem disse que precisamos sempre criar uma nova instancia de Pessoa na memoria? Diferente dos construtores, podemos nos beneficiar, por exemplo, do Design Pattern Flyweight que consiste em um pool de objetos Pessoa. Um exemplo:Voce sabe o que o metodo estatico valueOf() da classe java.lang.Integer faz? Abaixo o codigo do metodo:Se o valor passado como argumento estiver entre -128 e 127 sera retornado o objeto Integer imutavel existente no cache. Caso contrario, um novo objeto Integer sera criado (a cada requisicao). Performance!Terceira vantagem: Podem retornar qualquer subtipo do seu tipo de retorno.Muito interessante! Vamos supor que sua aplicacao passe a ter sub-tipos de Pessoa (exemplo, PessoaFisica / PessoaJuridica). Sera necessario encontrar todos os pontos da aplicacao em que a instanciacao