Acaba de ser lançada a mais nova ferramenta do google chamada GoogleCL. Esta ferramenta permite acesso aos serviços do google via linha de comando.

Segundo o próprio site da ferramenta, os seguintes serviços já são suportados:
* Blogger
$ google blogger post –title “foo” “command line posting”

* Calendar
$ google calendar add “Lunch with Jim at noon tomorrow”

* Contacts
$ google contacts list name,email > contacts.csv

* Docs
$ google docs edit –title “Shopping list”

* Picasa
$ google picasa create –title “Cat Photos” ~/photos/cats/*.jpg

* Youtube
$ google youtube post –category Education killer_robots.avi

Este é um grande avanço e facilita o acesso a quem, como eu utiliza bastante linha de comandos. Mais informações podem ser encontradas no próprio site da ferramenta, em http://code.google.com/p/googlecl.

Olá pessoal,

A bastante tempo não escrevo nada, mas hoje surgiu um assunto que acho ser uma pedra no sapato de vários desenvolvedores e arquitetos.

Enumerações, como o nome indica, são listas de valores associados a um conceito. Em java enumerações são subclasse da classe java.lang.Enum. Trabalhar com enumeração facilita bastante o trabalho do desenvolvedor, uma vez que fornece uma maneira de trabalhar com uma lista de valores finitas e trabalhar com tipos fortes em java.

Vejamos um exemplo simples de como isto pode ser um problema em sistemas.

1
2
3

public enum Sexo {
    MASCULINO, FEMININO;
}

Ao realizar o mapeamento desta enumeração com JPA 1.0 utilizamos normalmente a anotação @Enumerated. Com esta anotação sem nenhum parâmetro ou passando o parâmetro EnumType.ORDINAL, o valor a ser persistido no banco seria:

1
2

MASCULINO.ordinal()   == 0 
FEMININO.ordinal() == 1

Uma das desvantagens desta abordagem é o problema do valor persistido não ser significante para o negócio, o que gera a necessidade de dicionário de dados. Outra desvantagem é o fato de não poder adicionar novos valores no começo e no meio da enumeração uma vez que já existem dados gravados com estes valores no banco.

Outra abordagem seria utilizar a anotação @Enumerated passando como parâmetro o EnumType.STRING. Com esta abordagem o valor a ser persistido passa a ser o método name da enumeração que é mostrado abaixo:

1
2

MASCULINO.name = "MASCULINO"
FEMININO.name = "FEMININO"

Esta abordagem também possui alguns problemas. O maior deles é a briga que vc terá com qualquer DBA a respeito do que deveria ser gravado no campo. O que qualquer DBA falará é que deveria ser gravado no banco os valores ‘M’ ou ‘F’ para ter menos gasto de memória e melhor indexação do campo.

Uma abordagem que acho a melhor seria gravar no banco o valor ‘M’ ou ‘F’, mas continuar trabalhando com a enumeração com os nomes MASCULINO e FEMININO.

Uma maneira de realizarmos esta modificação no código para funcionar desta maneira é mostrada abaixo:

Enumeração:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public enum SexoEnum {
	MASCULINO("M"), FEMININO("F");
 
	private final String value;
 
	SexoEnum(String value) {
		this.value = value;
	}
 
	public static SexoEnum fromValue(String value) {
		if (value != null) {
			for (SexoEnum sexo : values()) {
				if (sexo.value.equals(value)) {
					return sexo;
				}
			}
		}
		throw new IllegalArgumentException("Sexo invalido: " + value);
	}
 
	public String toValue() {
		return value;
	}
}

Na classe a ser mapeada o código ficaria próximo ao exemplo abaixo:

@Entity
public class Pessoa {
 
	@Column(length = 1)
	private String sexo;
 
	@Transient
	public SexoEnum getSexoEnum() {
		return SexoEnum.fromValue(sexo);
	}
 
	public void setSexoEnum(SexoEnum sexoEnum) {
		this.sexo = sexo.toValue();
	}
}

Mapeando desta maneira trabalhamos então com o melhor dos dois mundos. Outra maneira bastante interessante de realizar o mapeamento seria a utilização do UserType do Hibernate, mas falamos disto em outro post.

Mais informações podem ser encontradas em http://www.vineetmanohar.com/2010/01/3-ways-to-serialize-java-enums.

É isto aí pessoal. Qualquer problema avisem…

Pessoal,

Venho convidá-los para um evento da Comunidade JBoss Brasil. O evento irá acontecer em SP e conta com a participação de vários líderes de projetos Open Source. Segue mais detalhes do evento:

Evento

Horário: 7 maio 2010 às 14:00 a 8 maio 2010 às 20:00
Local: Anhembi Morumbi – Casa do Ator, Campos Vila Olimpia
Organizado por: Land do Brasil

http://jbossbrasil.ning.com/events/event/show?id=2234825%3AEvent%3A19199&xgi=48yfZiTpQVlyHY&xg_source=msg_invite_event

É um evento bem interessante e com certeza contribuirá bastante para arquitetos e desenvolvedores.

[]s,

Samuel

Olá pessoal,

Hoje vamos ver um pouco como funciona o padrão Factory Method. Este é um padrão de Criação (Creational Pattern) e lida com o problema de criação de objetos.

Problema

Este padrão é utilizado quando você deseja criar um objeto sem especificar qual a classe vai ser utilizada. O padrão resolve isso definindo uma interface para criar um objeto, mas deixando as subclasses decidirem que classe instanciar.

Figura 1: Diagrama de Classes para o Factory Method.

Utilizando nosso exemplo anterior (veja Abstract Factory) no nosso código de uma aplicação GED poderíamos utilizar o padrão Factory Method junto com o Abstract Factory. Com o Abstract Factory nos criamos as familias de objetos relacionados e com o Factory Method nos criamos a fabrica que realmente vai instanciar o classe. Ou seja, nós delegamos a factory a responsabilidade de escolher que classe instanciar.

Figura 2: Diagrama de Classes para o Factory Method do exemplo.

Implementação

Observe que modificamos as factorys do Abstract Factory (compare com o post sobre Factory Method) para agora chamar a respectiva Factory Method. Classes modificadas:
PdfDocumentFactory, TxtDocumentFactory.

package br.ged.abstractfactory.concrete;
 
import br.ged.abstractfactory.interfaces.DocumentFactory;
import br.ged.abstractfactory.interfaces.DocumentReader;
import br.ged.abstractfactory.interfaces.DocumentWriter;
import br.ged.factorymethod.DocumentReaderFactory;
import br.ged.factorymethod.DocumentWriterFactory;
 
public class PdfDocumentFactory implements DocumentFactory
{
 
	@Override
	public DocumentReader createDocumentReader( )
	{
		System.out.println( "PdfDocumentFactory.createDocumentReader ::: PDF" );
 
		// AQUI ESTA A NOSSA FACTORY METHOD
		return DocumentReaderFactory.getReader( DocumentFactory.PDF );
	}
 
	@Override
	public DocumentWriter createDocumentWriter( )
	{
		System.out.println( "PdfDocumentFactory.createDocumentWriter ::: PDF" );
 
		// AQUI ESTA A NOSSA FACTORY METHOD
		return DocumentWriterFactory.getWriter( DocumentFactory.PDF );
	}
}

package br.ged.abstractfactory.concrete;
 
import br.ged.abstractfactory.interfaces.DocumentFactory;
import br.ged.abstractfactory.interfaces.DocumentReader;
import br.ged.abstractfactory.interfaces.DocumentWriter;
import br.ged.factorymethod.DocumentReaderFactory;
import br.ged.factorymethod.DocumentWriterFactory;
 
public class TxtDocumentFactory implements DocumentFactory
{
 
	@Override
	public DocumentReader createDocumentReader( )
	{
		System.out.println( "TxtDocumentFactory.createDocumentReader ::: TXT" );
 
		// AQUI ESTA A NOSSA FACTORY METHOD
		return DocumentReaderFactory.getReader( DocumentFactory.TXT );
	}
 
	@Override
	public DocumentWriter createDocumentWriter( )
	{
		System.out.println( "TxtDocumentFactory.createDocumentWriter ::: TXT" );
 
		// AQUI ESTA A NOSSA FACTORY METHOD
		return DocumentWriterFactory.getWriter( DocumentFactory.TXT );
	}
 
}

package br.ged.factorymethod;
 
import br.ged.abstractfactory.interfaces.DocumentReader;
 
public abstract class ReaderFactory
{
	public static DocumentReader getReader( String readerType ){ return null; }
}

package br.ged.factorymethod;
 
import br.ged.abstractfactory.interfaces.DocumentWriter;
 
public abstract class WriterFactory
{
	public static DocumentWriter getWriter( String readerType ){ return null; }
}

package br.ged.factorymethod;
 
import br.ged.abstractfactory.concrete.PdfDocumentReader;
import br.ged.abstractfactory.concrete.TxtDocumentReader;
import br.ged.abstractfactory.interfaces.DocumentFactory;
import br.ged.abstractfactory.interfaces.DocumentReader;
 
public class DocumentReaderFactory extends ReaderFactory
{
	public static DocumentReader getReader( String readerType )
	{
		if ( readerType != null && readerType.equalsIgnoreCase(  DocumentFactory.TXT ) )
		{
			return new TxtDocumentReader( );
		}
		else if ( readerType != null && readerType.equalsIgnoreCase(  DocumentFactory.PDF ) )
		{
			return new PdfDocumentReader( );
		}
		return null;
	}
}

package br.ged.factorymethod;
 
import br.ged.abstractfactory.concrete.PdfDocumentWriter;
import br.ged.abstractfactory.concrete.TxtDocumentWriter;
import br.ged.abstractfactory.interfaces.DocumentFactory;
import br.ged.abstractfactory.interfaces.DocumentWriter;
 
public class DocumentWriterFactory extends WriterFactory
{
	public static DocumentWriter getWriter( String readerType )
	{
		if ( readerType != null && readerType.equalsIgnoreCase( DocumentFactory.TXT ) )
		{
			return new TxtDocumentWriter( );
		}
		else  if ( readerType != null && readerType.equalsIgnoreCase( DocumentFactory.PDF ) )
		{
			return new PdfDocumentWriter( );
		}
 
		return null;
	}
}

Utilizações comuns

Utilize quando quiser postergar a instanciação de suas classes.

Uma classe quer que suas subclasses especifiquem os objetos que criam.

Quando a escolha de qual classe instanciar for tomada em tempo de execução.

Conseqüências

Segundo GoF o padrão Abstract Factory tem as seguintes vantagens e desvantagens:

- elimina a necessidade de anexar classes especificas das aplicações no código

- fornece um gancho para as subclasses. A criação de classes e subclasses se torna mais

flexível.

- como desvantagem podemos citar o fato de que podemos ter que criar varias subclasses da classe Creator apenas para criar um ConcreteProduct.

Conclusões

O padrão Factory Method é um velho conhecido dos programadores Java. Ele esta presente em Collections. Em Collections o método iterator é uma Factory Method. Pense aqui: ele cria um objeto, retorna uma interface, é implementado por várias classes. Este padrão é justamente sobre isso: diversas classes que implementam a mesma operação, retornam as mesma interface (ou classe abstrata) mas retornam diferentes implementações.

Por hoje é só pessoal.

Performance

Olá pessoal,

Tenho encontrado constantemente sites com problemas sérios de performance. Algumas das vezes temos problemas estruturais sérios, mas algumas vezes os problemas podem ser simples de resolver e pequenos ajustes representam grande melhoria na experiência do usuário.

Quando dizemos performance de aplicações, logo os desenvolvedores pensam em grandes mudanças estruturas como cluster, melhorias na JVM, máquinas novas, cache de banco de dados e outras. Isto também são melhoras importantes, mas quando se trata de aplicações web, a percepção da performance pelo usuário, pode ser melhorada por otimizações mais simples como mudanças no front-end da aplicação.

Podemos encontrar as melhores práticas sobre performance de aplicações web em http://developer.yahoo.com/performance/rules.html. Entre as dicas descritas no documento acima temos:

* Fazer menos requisições HTTP

* Adicionar um cabeçalho “Expires” na resposta HTTP

* Utilizar Gzip para compactar os componentes da página

* Colocar os Stylesheets no topo da página

* Colocar os Scripts no fim da página

* Evitar CSS Expressions

* Colocar os códigos JavaScript e CSS em arquivos externos

* Reduzir DNS Lookups

* Compactar os códigos JavaScript

* Remover Scripts duplicados

* Evitar Redirects

* Configurar as ETags

* Make Ajax Cacheable

Uma ferramenta que auxilia bastante é o addon do mozilla YSlow que é desenvolvido pela Yahoo. Este addon analisa com base nas melhores práticas documentadas no artigo com link acima quais regras estão ou não sendo seguidas.

Uma dica que me ajudou bastante em algumas aplicações que trabalhei foi a de habilitar a compressão de páginas. Existem páginas que são grandes, o que faz com que o acesso seja lento em conexões de rede ruins.

Esta compressão de página basicamente troca o requisito banda por CPU. Os passos realizados para a compressão são os seguintes:

1 – O browser do cliente faz uma requisição e envia para o servidor no cabeçalho que o browser aceita arquivos comprimidos.

2 – O servidor verifica que o browser que fez a requisição aceita arquivos comprimidos.

3 – O servidor comprime a página e envia para o cliente.

4 – O cliente descompacta a página recebida e exibe para o usuário.

Podemos utilizar para a compressão de página o apache com o módulo mod_deflate. Para explicações mais detalhadas sobre como funciona o mod_deflate verifiquem a documentação em http://httpd.apache.org/docs/2.0/mod/mod_deflate.html.

É isto ai pessoal. Espero que vocês sigam as orientações, para o bem de suas aplicações e de seus usuários.

A especificação JEE foi finalizada em Dezembro de 2009, trazendo algumas características novas e outras atualizadas para o mundo do desenvolvimento de aplicações corporativas. Temos por exemplo, a introdução de um novo conceito: a abordagem por perfis (profile approach), que foca nas divisões por áreas de interesse entre os desenvolvedores de aplicação, sendo o Web Profile o primeiro profile definido pelo expert group, o qual objetiva fornecer o mínimo de esforço de configuração aos desenvolvedores de aplicação web típicas. O objetivo deste post é dar uma breve descrição das novidades que pesquisei e achei mais interessantes. Espero que gostem.

Um pouco das principais novidades do web profile:

- Servlet 3.0:

Em frameworks web, os servlets são comumente utilizados como um ponto de entrada da aplicação para processar as requisicões, poderiamos dizer então que eles são o núcleo de aplicações web. A nova versão 3.0 (JSR-315) oferece características inovadoras, tais como as anotações pertinentes a esses tipos de classes, tal como a @Servlet, @ServletFilter e @ServletContextListener, permitindo ao desenvolvedor, criar a classe como se fosse um POJO, uma classe simples, que não se prende à implementação das interfaces como era requerido nas versões anteriores. Com isso também são fornecidas uma maior flexibilidade e extensibilidade, já que ao integrar a sua aplicação a um framework MVC, você não precisaria de configurações extras.

- Integração entre XML’s de configuração:

Arquivos xml dos frameworks agora podem vir dentro de seus próprios arquivos JAR, já que temos uma interessantíssima novidade aqui: o contêiner JEE6 também agora tem a responsabilidade de “unir” todos os arquivos que se referem a fragmentos web.

- Java Server Pages (JSP) na versão 2.2;

- Expression Language (EL) também em sua versão 2.2;

- Bibliotecas padrão para o JSP (JSTL) na sua versão 1.2;

- Java Server Faces (JSF) na versão 2.0:

Desde que a release do JSF 1.x saiu, o JSF foi apontado como um dos frameworks mais promissores do mercado. A sua fama entusiasmou desenvolvedores ao redor do mundo todo, fazendo com que fosse crescendo em inúmeras características agregadas, tais como componentização, validação, navegação, suporte à internacionalização (também conhecido como i18n) entre outras. No entanto, com todas essas características benéficas, algumas falhas e desvantagens foram ficando mais evidentes com o passar do tempo, tal como o quão é considerado complicado criar tarefas simples através da criação de componentes customizados.  A versão 2.0 vêm com o objetivo de remediar tais falhas facilitando o desenvolvimento e introduzindo novas características, tais como suporte a ajax integrado, os quais eram realizados apenas por implementações específicas e não propostas pela especificação JSF em si.

Algumas das grandes novas características do JSF 2.0:

• Composição de componentes

Para implementar componentes customizados utilizando JSF 1.x era realmente uma tarefa nada simples. Você teria que implementar um componente visual (UI componente) e a classe tag, com a opção também de um Renderer para a marcação e então configurar tudo isso dentro do arquivo faces-config.xml e arquivos tld (Ufssss pausa pra retomar o ar!!!). JSF 2.0 simplica isso tudo através da abordagem de componentes compostos introduzidas com o Facelets.

• Suporte integrado a Ajax

Agora você pode utilizar-se dos poderes do ajax com toda sua API e infra-estrutura através das tags f:ajax sem se importar com a tecnologia em particular que está realizando essa implementação.

• Manutenção de estado de objetos

JSF 2.0 vem com uma solução para manipular requisições particulares com classes tais como PartialViewContext e PartialStateHolder, fazendo o uso de mecanismos responsáveis por guardar o estado dos objetos manipulados nessas requisições parciais. Isto já havia sido implementado antes pelo uso do Apache Trinidad, porém, estas novas classes provêm uma maneira mais elegante de realizar tal manipulação. O objetivo é ter uma versão “leve” do estado salvo para ir e voltar nas navegações de páginas web.

• Novos escopos

Em adição ao escopo de página (page), requisição (request), sessão (session) e aplicação (application), JSF 2.0 também introduz os chamados escopos View e Flash. Os beans cujo escopo é de View têm um ciclo de vida que é maior que uma requisição, mas é menor que beans no escopo de sessão. Já os escopos Flash são como os escopos View que irão viver dentro de uma determinada view, incluindo redirecionamentos, e que serão removidos se você os estiver movendo para uma outra view.

• Navegação

No JSF 1.x toda regra de navegação deveria ser adicionada ao facez-config.xml. Com a versão 2.0, navegações implícitas também podem ser usadas, no caso de uma saída retornada por um método do bean corresponder a um view id de mesmo nome. Agora também é possível se fazer navegações condicionais dentros das tags navigation-case através de marcações de expressões regulares dentro do face-config. A versão 2.0 também provê facilidades para requisições via método GET para os componentes h:link and h:button, suportando a integração de parâmetros na requisição. O benefício de se usar tais componentes é o de tornar suas páginas passíveis de serem adicionadas aos favoritos (bookmark).

• Configuração com Annotations

Você pode agora anotar seus beans com as novas anotações @ManagedBean e pode também       especificar o escopo do bean através das anotações @RequestScoped, @SessionScoped, @ViewScoped, @NoneScoped entre outras.

Outras novidades:

- Enterprise JavaBeans (EJB) 3.1 Lite;

- Java Transaction API (JTA) 1.1;

- Java Persistence API (JPA) 2.0;

Na minha opinião, as principais características desta release são a nova API para queries criteria e o suporte à validações.

- Contexts and Dependency Injection (CDI)

Em atendimento à Java Specification Request JSR-299, o propósito desta especificação é unir o modelo de componentes do JSF Managed-Beans com o modelo de componentes EJB, proporcionando um modelo de fácil implementação para aplicações web. CDI também torna possível para outros componentes JEE interagirem uns com os outros usando o design pattern Observer. Isto nos facilita, por exemplo, integrar enterprise beans com suporte transacional, através do lançamento de eventos de um para o outro. JSR 330 também se tornou parte do JEE 6, oferecendo um conjunto de anotações padrão que podem ser usadas para a injeção de dependência, como por exemplo, as @Named, @Inject, @Qualifier entre outras. A WELD é a implementação de referência para o CDI.

- Bean Validation and Hibernate Validator

A Bean Validation, JSR 303, define uma modelo de metadados e uma API para validação de beans. Sua implementação de referência é a Hibernate Validator que, em sua última versão, adiciona alguns recursos legais, tais como agrupamento de validações, integração nativa com JPA 2 e JSF 2, além de um conjunto de anotações novas.

É isso aí pessoal, isso aqui foi só uma palinha do que de mais novo está acontecendo dentro das implementações corporativas Java, e como vocês puderam notar, JEE 6 vem bombando de novidades que aparentemente demonstram o quanto esta arquitetura vêm evoluindo em uma tendência a padronizar o que já vem sendo escrito por diversos frameworks: abordagem que exigem menos configurações e alto nível de acoplamento automático de implementações independentes. Na página da Sun vocês podem conferir a lista completa.

Agora é só esperarmos a comunidade java agitar com seus primeiros projetos para que a quantidade de exemplos e tutoriais aumentem!

E vocês, podem citar outras importantes novidades do JEE 6?

Um grande abraço e até o próximo post!

O padrão Abstract Factory

Abstract Factory é um padrão de criação e como o nome diz ‘Fabrica Abstrata’ este padrão é utilizado para a criação de objetos relacionados ou ‘família de objetos’.

Figura 1: Diagrama de Classes para o Abstract Factory.

Problema

Precisamos criar famílias de objetos relacionados e cada objeto de cada família tem sua implementação especifica. Você precisa garantir que dada uma situação você escolherá a família correta de objetos que será utilizado sem misturar os objetos de famílias diferentes.

Imagine que você esteja desenvolvendo uma aplicação de gerenciamento de documentos (GED) e precise tratar diferentes tipos de arquivos: txt, pdf, doc e etc.

Dentro deste contexto você terá objetos para extração e indexação de conteúdo para cada tipo de arquivo (mime-type).

Figura 2: Diagrama de Classes para o Abstract Factory do nosso exemplo.

Implementação

Observe que na classe Client utiliza somente as interfaces não as implementações.

package br.ged.abstractfactory.interfaces;
 
public interface DocumentFactory 
{
	public static final String TXT = "TXT";
 
	public static final String PDF = "PDF";
 
	public DocumentReader createDocumentReader( );
 
	public DocumentWriter createDocumentWriter( );
 
}

package br.ged.abstractfactory.interfaces;
 
import java.io.OutputStream;
 
public interface DocumentReader {
 
	public OutputStream readeFile( String file );
 
}

package br.ged.abstractfactory.interfaces;
 
import java.io.InputStream;
 
public interface DocumentWriter {
 
	public void writeFile( InputStream inputStream );
 
}

package br.ged.abstractfactory.concrete;
 
import br.ged.abstractfactory.interfaces.DocumentFactory;
import br.ged.abstractfactory.interfaces.DocumentReader;
import br.ged.abstractfactory.interfaces.DocumentWriter;
 
public class PdfDocumentFactory implements DocumentFactory 
{
 
	@Override
	public DocumentReader createDocumentReader( ) 
	{
		System.out.println( "PdfDocumentFactory.createDocumentReader ::: PDF" );
		return new PdfDocumentReader( );
	}
 
	@Override
	public DocumentWriter createDocumentWriter( ) 
	{
		System.out.println( "PdfDocumentFactory.createDocumentWriter ::: PDF" );
		return new PdfDocumentWriter( );
	}
 
}

package br.ged.abstractfactory.concrete;
 
import java.io.OutputStream;
 
import br.ged.abstractfactory.interfaces.DocumentReader;
 
public class PdfDocumentReader implements DocumentReader {
 
	@Override
	public OutputStream readeFile( String file ) {
		System.out.println( "PdfDocumentReader.readeFile ::: PDF" );
		return null;
	}
 
}

package br.ged.abstractfactory.concrete;
 
import java.io.InputStream;
 
import br.ged.abstractfactory.interfaces.DocumentWriter;
 
public class PdfDocumentWriter implements DocumentWriter {
 
	@Override
	public void writeFile(InputStream inputStream) {
		System.out.println( "PdfDocumentWriter.writeFile ::: PDF" );
	}
 
}

package br.ged.abstractfactory.concrete;
 
import br.ged.abstractfactory.interfaces.DocumentFactory;
import br.ged.abstractfactory.interfaces.DocumentReader;
import br.ged.abstractfactory.interfaces.DocumentWriter;
 
public class TxtDocumentFactory implements DocumentFactory 
{
 
	@Override
	public DocumentReader createDocumentReader( ) 
	{
		System.out.println( "TxtDocumentFactory.createDocumentReader ::: TXT" );
		return new TxtDocumentReader( );
	}
 
	@Override
	public DocumentWriter createDocumentWriter( ) 
	{
		System.out.println( "TxtDocumentFactory.createDocumentWriter ::: TXT" );
 
		return new TxtDocumentWriter( );
	}
 
}

package br.ged.abstractfactory.concrete;
 
import java.io.OutputStream;
 
import br.ged.abstractfactory.interfaces.DocumentReader;
 
public class TxtDocumentReader implements DocumentReader {
 
	@Override
	public OutputStream readeFile(String file) {
		System.out.println( "TxtDocumentReader.readeFile ::: TXT" );
		return null;
	}
}

package br.ged.abstractfactory.concrete;
 
import java.io.InputStream;
 
import br.ged.abstractfactory.interfaces.DocumentWriter;
 
public class TxtDocumentWriter implements DocumentWriter {
 
	@Override
	public void writeFile(InputStream inputStream) {
		// persiste arquivo baseado no inputstream
		System.out.println( "TxtDocumentWriter.writeFile ::: TXT" );
	}
 
}

package br.ged.abstractfactory.concrete;
 
import java.io.OutputStream;
 
import br.ged.abstractfactory.interfaces.DocumentFactory;
import br.ged.abstractfactory.interfaces.DocumentReader;
import br.ged.abstractfactory.interfaces.DocumentWriter;
 
public class Client 
{
    public static void main(String[] args) throws Exception
    {
    	// OBSERVE QUE USAMOS AQUI APENAS AS INTEFACES
	    DocumentFactory documentFactory =  createDocumentFactory( "PDF" );
 
	    DocumentWriter documentWriter = documentFactory.createDocumentWriter();
	    documentWriter.writeFile( null );
 
	    DocumentReader documentReader = documentFactory.createDocumentReader();
	    OutputStream outputStream = documentReader.readeFile("dados.txt");
 
	}
 
    public static DocumentFactory createDocumentFactory( String type ) 
    {
    	if ( type.equalsIgnoreCase( DocumentFactory.PDF ) )
    		return new PdfDocumentFactory();
    	if( type.equalsIgnoreCase( DocumentFactory.TXT ) )
    		return new TxtDocumentFactory();
 
    	return null;
    }
}

Utilizações comuns

Utilize quando quiser ter independência de como seus objetos são criados, ou seja você deseja desacoplar sua aplicação e as famílias de objetos utilizadas por ela. Dessa forma podemos trocar a família de objetos utilizadas na aplicação sem afetar o código fonte.

Utilize quando quiser fornecer uma biblioteca de classes de produtos e quer revelar somente suas interfaces e as implementações.

Conclusões

Embora utilizar o AbstractFactory gere um trabalho adicional (escrever produtos abstratos, fabricas abstratas, e suas respectivas implementações) , utilizar fabricas é uma boa prática de programação e ajuda a reduzir o acoplamento e conseqüentemente melhora manutenção do sistema.

Olá pessoal,

Há bastante tempo não escrevo nada. Resolvi falar agora sobre melhorias de performance que ajudam bastante a aplicação. Em sites, constantemente temos páginas que acessam várias consultas pesadas além de regras de negócio. Estas páginas quando muito acessadas causam freqüentemente problemas de desempenho na aplicação e páginas lentas.

Um dado importante para se tomar a decisão de utilizar ou não cache em páginas é a relação entre corretude e performance. Imagine o seguinte caso: Você tem uma página que possui as últimas notícias da sua empresa. Se uma nova notícia nova acaba de sair, qual o impacto da notícia demorar um pouco a mais para entrar no ar? O ganho de performance vale a pena o atraso na notícia. Se sim é interessante utilizar neste caso o cache para esta página.

Quando temos cenários parecidos com este podemos verificar se é possível realizar cache de páginas. O Ehcache que é um framework java possui além do cache de objetos e cache para acesso a dados com JPA, possui também cache de páginas. Este cache às vezes é mais interessante, porque uma mesma página pode possuir várias consultas e regras de negócio, o que faz com que o cache de página geralmente gere mais ganho de performance do que o cache de acesso a dados.

Para definir o cache de páginas é necessário primeiramente baixar os jars do ehcache disponíveis em http://ehcache.org. Entre os jars necessários é necessário baixar o módulo ehcache-web, que possui a Servlet responsável por gerenciar e guardar o cache das páginas.

Depois disto, no classPath (pode ser na pasta src por exemplo) deve ser adicionado o aquivo ehcache.xml com um conteúdo parecido com o abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
    <diskStore path="java.io.tmpdir" />
    <cache name="SimplePageCachingFilter" maxElementsInMemory="10"
        eternal="false" timeToIdleSeconds="600" timeToLiveSeconds="600"
        overflowToDisk="true" />
 
    <defaultCache maxElementsInMemory="10" eternal="false"
        overflowToDisk="false" timeToIdleSeconds="120" timeToLiveSeconds="120"
        diskPersistent="false" diskExpiryThreadIntervalSeconds="120" />
</ehcache>

Para o arquivo acima é necessário verificar o tempo de expiração do cache que é definido pela propriedade timeToLiveSeconds que representa o número de segundos do cache da página apresentada.

Depois, no arquivo web.xml devemos adicionar o filtro de cache para as páginas necessárias, assim como mostrado abaixo:

<!-- Filtros para cache de páginas adicionado para páginas não logadas -->
<filter>
    <filter-name>SimplePageCachingFilter</filter-name>
    <filter-class>net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>SimplePageCachingFilter</filter-name>
    <url-pattern>/index.jsf</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>SimplePageCachingFilter</filter-name>
    <url-pattern>/noticias.jsf</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>SimplePageCachingFilter</filter-name>
    <url-pattern>/rss.jsf</url-pattern>
</filter-mapping>

A melhoria de performance é bastante significante. Além do cache de páginas comum é possivel também compactar as páginas, adicionar cabeçalhos, entre outros. Para mais informações visitem http://ehcache.org/documentation/web_caching.html.

É isto aí pessoal. Qualquer problema avisem…