Em Java a criação de um objecto é feito da seguinte maneira:

XPTO objecto = new XPTO();

Mas neste caso, temos que a criação de objectos é um pouco inflexível uma vez que estes são sempre do mesmo tipo. Em muitos casos, a natureza dos objectos que são criados pode variar com as necessidades do programa e, a abstracção do processo de criação de objectos para uma classe especial de “criação“, pode tornar o seu programa mais flexível e geral. Assim surge o Factory Method.

Intenção

O Factory Method é criado com a intenção de definir uma interface para a criação de objectos, mas permitir que sejam as classes derivadas a decidir qual a classe a instanciar.

Aplicabilidade:

Utilizar o padrão Factory Method quando:

• Uma classe não pode antecipar a classe dos objectos que deve criar;
• Uma classe pretende que sejam as suas classe derivadas a especificar os objectos que devem ser criados.

A sua representação pode ser expressa da seguinte forma (representação em UML):

Explicando as entidades:

· Creator - declara o factory method (método de fabricação) que retorna o objecto da classe Product (produto). Este elemento também pode definir uma implementação básica que retorna um objecto de uma classe ConcreteProduct (produto concreto) básica;

· ConcreteCreator – deriva do factory method e retorna um objecto da classe ConcreteProduct;

· Product – define uma interface para os objectos criados pelo factory method;

· ConcreteProduct – uma implementação para a interface Product.

Vamos ver um exemplo bastante simples:

Para entender como o padrão Factory funciona, vamos observar o seguinte diagrama:

Carro é a classe base (pai) e as classes Vectra, Omega, Gol e Golf derivam dela (filhos).

A classe CarroFactory é a classe Factory que decide qual das subclasses retornar, dependendo dos argumentos que você passar ao método factory dela.

Nós definimos o método getCarro(), como o método factory que recebe um parâmetro (tipo de objecto) e retorna uma instância da classe Carro, representado no diagrama por :carro.

Não importa ao programador qual a classe que ele retorna, desde que todos eles tenham os mesmos métodos, mas diferentes implementações. Qual a subclasse de Carro que será retornada é estritamente decidido pela classe CarroFactory.

Vamos considerar um caso simples onde nós podemos usar uma classe Factory. Suponha que nós temos um sistema de consulta de preços de veículos. Informamos qual o carro queremos consultar o respectivo preço. Então a classe factory retorna-nos a respectiva instância e então consultamos o preço.

Vamos observar a implementação:

Agora a nossa classe Factory, que é bem simples, decide qual classe será instanciada, dependendo do parâmetro do tipo passado para o método getClass( ).

O FactoryExample irá ser o nosso main:

Desta forma, vemos que a partir dos argumentos dados a classe CarroFactory devolve o o respectivo objecto.

Referências:

[http://pt.wikipedia.org/wiki/Factory_Method]

[http://www.guj.com.br/java.tutorial.artigo.137.1.guj]

[http://www.javacamp.org/designPattern/factory.html]

A ideia dos Padrões de Desenho consiste em descrever soluções para problemas semelhantes, descrevendo também sempre a respectiva solução.

O que é uma design pattern? É uma descrição de um problema que ocorre com frequência, acompanhada do design da sua solução. Uma pattern tem quatro elementos essenciais: um nome, uma descrição de quando a pattern deve ser usada, a solução e as consequências dessa solução.

O conceito de padrão de projecto foi criado na década de 70 pelo arquiteto Christopher Alexander. Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, ele estabelece que um padrão deve ter, idealmente, as seguintes características:

• encapsulamento: um padrão encapsula um problema/solução bem definido. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.
• generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão.
• equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projecto. Uma análise racional que envolva uma abstracção de dados empíricos, uma observação da aplicação de padrões em artefactos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.
• abstração: os padrões representam abstracções da experiência empírica ou do conhecimento quotidiano.
• abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
• combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.

Referências:

[http://psantos.zi-yu.com/wiki.aspx?topic=PRE.DesignPatterns]

[http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software]

Realmente o WordPress mostra-se como uma ferramenta opensource poderosa para construir blogs. Sendo fácil de utilizar e oferecendo muitas opções, a WordPress é uma ferramenta completa e muito útil para quem estiver interessado em construir o seu próprio blog. É o preferido de muitos e, não sendo o meu caso pois este é o primeiro blog pessoal, é considerado também por muitos “o melhor”.

Por isso, se alguém estiver interessado em construir o seu próprio blog aconselho a WordPress.

Cumprimentos,

Cristian.