Atualmente o termo padrões de projeto, ou design patterns é cada vez mais falado entre desenvolvedores, analistas e arquitetos de TI. É esperado que profissionais Plenos ou Seniores conheçam muito bem os principais padrões e estejam aptos a aplicar os mesmos em seus projetos.
A idéia deste post é descrever basicamente o que são os tais padrões de projeto e citar os principais.
Basicamente padrões de projeto
são soluções reutilizáveis para problemas comuns. Como assim? Vamos supor que você quer implementar um software que precisa se conectar ao banco de dados e retornar dados para o usuário, porém você não quer que o programador entre em contato com a regra de negócio, pois esta vai ser desenvolvida por um outro programador mais sênior, então você pode utilizar um padrão chamado Business Delegate, que basicamente fornece uma camada com a qual o programador júnior vai poder interagir.
Um termo muito falado sobre o tema é o tal de GOF, ou Gang of Four. Fala-se gangue dos 4 pois trata-se de uma coleção de 19 padrões de projeto documentados elaborados por
4 pessoas: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Existe um ótimo livro sobre o tema que inclusive eu recomendo: "
Padrões de Projeto", pode ser visto e comprado
aqui.Os padrões do GOF podem ser utilizados nas linguagens Orientadas a Objetos, não é algo específico para Java. Dentre os mais conhecidos, posso citar:
- Abstract Factory: Fornece uma interface para se criar uma família de objetos que tem características em comum. Não especifica a classe concreta. Um exemplo seria um criador de documentos que pode criar um e-mail ou um pdf.
- Adapter (or wrapper ): Como o nome diz, é um adaptador. Ele permite que classes que normalmente não poderiam interagir devido a interfaces incompatíveis, o façam. Este padrão prove uma interface que pode ser utilizada pela classe anteriormente incompatível.
- Prototype: É um padrão de criação que baseia-se na criação de objetos através da clonagem de um protótipo, utilizando o método clone() ao invés do new(), dessa forma evitamos custos.
- Facade: Fornece uma interface única e simplificada para uma série de interfaces em um sistema. Por exemplo, nós temos muito código para iniciar algum processo, envolvendo N classes e métodos, então, ao invés de replicar este mesmo código em todos os locais de nossa aplicação que utilizem este processo, podemos criar um facade que encapsula o processo e que recebe somente o que for necessário para o processo.
- Singleton: Esta é o mais famoso e mais questionado em entrevistas. Basicamente seu objetivo é garantir que haverá somente uma instância do objeto em memória, não importando quantas vezes ele será chamado/construído.
Além do GOF, temos os padrões de projeto
Enterprise, que como o nome diz, são indicados para aplicações enterprise, a listagem completa dos mesmos pode ser vista
aqui .
Um ótimo livro sobre o assunto pode ser visto aqui . Os padrões mais comuns são:
- Business Delegate: É como uma camada que permite que os clientes (programas, classes, etc) não interajam diretamente com os serviços/classes de negócio. Com esta "camada" de bando de dados, nos reduzimos o acoplamento entre a camada de apresentação e os serviços de negócio, por exemplo, a camada de apresentação passa os parâmetros para a camada de negócio e assim "delega" o restante do processo a mesma, dessa forma, estamos escondendo a implementação do negócio das camadas superiores da aplicação.
- Data Access Object (DAO): Esse é o mais comum! Um DAO abstrai e encapsula todo o acesso a uma fonte de dados. O DAO gerencia a conexão, obtêm e armazena dados!
- DataSource (DS): É a representação da fonte de dados. Um DS pode ser um banco de dados, um arquivo XML, etc...
- TransferObject (TO): É utilizado para transferir dados entre uma aplicação e algum componente tal como um EJB, é como um contêiner que transporta "coisas". Normalmente, nós temos um DAO que utiliza um TO para retornar dados para um cliente, também normalmente criando um objeto do tipo VO (Value Object) com os dados do TO.
Certamente a breve descrição dos padrões enterprise não deve ter ajudado muito, pois os mesmos são mais complexos, para seu entendimento é necessário mais estudo e implementação do que uma breve leitura.
Finalmente, esta foi somente a ponta do iceberg! Que sirva como uma breva introdução. Espero ter colaborado com este breve artigo!
Enjoy!
