Padronizando seus projetos no mundo corporativo – Introdução – Parte I

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (3)  (1)

Este artigo irá abordar os aspectos relativos a aplicação de padrões de projeto nas soluções corporativas de software.

 

Este artigo irá abordar os aspectos relativos a aplicação de padrões de projeto nas soluções corporativas de software. Antes de começarmos a adentrar no mundo prático dos padrões de projeto, iremos fazer uma abordagem inicial e descrever o catálogo escolhido. Este artigo utilizou como base o livro Core J2EE Patterns e Design Patterns – Elements of Reusable Object-Oriented Software (GoF) para descrição e definição do catálogo de padrões.

 

O que são padrões de projeto?

Também conhecido como Design Patterns em inglês, os padrões de projeto são documentos que fornecem soluções para problemas recorrentes em um determinado contexto. Com isso, esses documentos permitem evitar a reinvenção da roda na tentativa da resolução de problemas, agilizando o desenvolvimento pela utilização de paradigmas já testados.

 

Além disso, os padrões de projeto são definidos estruturalmente e cada um estabelece um nome, sua descrição, o contexto com exemplos (diagramas, figuras ou descrição que ilustrem um protótipo), definem o problema, a solução, quando aplicar esta solução e suas conseqüências.

 

Benefícios

O uso de padrões de projeto nas aplicações promove os seguintes benefícios:

  • Passamos a ter um vocabulário comum para conversar sobre projetos de software.
  • Limitamos o espaço de soluções.
  • Soluções que não tinham passam a ter um nome.
  • Os padrões de projetos são reutilizáveis por natureza.
  • Contém as melhores práticas na solução de um dado problema.
  • Facilitam a documentação e aprendizado através da nomenclatura padrão utilizada.
  • Podem ser (e normalmente são) utilizados em conjunto para resolver um problema de grande porte.

 

Catálogo escolhido

Os padrões foram escolhidos com base no desenvolvimento e soluções para problemas em softwares corporativos. Para os exemplos de aplicações reais serão utilizados: o Java 2 Enterprise Edition 5.0, alguns frameworks de desenvolvimento, além de diagramas UML.

 

Não utilizaremos nenhuma classificação, pois elas podem se sobrepor de acordo com o padrão escolhido.

 

Os nomes dos padrões para esse catálogo serão mantidos em inglês para facilitar a reutilização em projetos que não são necessariamente feitos em português.

Abaixo descreveremos sucintamente os padrões de projeto selecionados para este catálogo.

 

Abstract Factory

Provê uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.

 

Adapter

Converte a interface de uma classe em outra interface desejada. O Adapter permite que classes com interfaces incompatíveis possam interagir, o que anteriormente não era possível.

 

Bridge

Diminui o acoplamento entre a abstração (interface) e sua implementação, dessa forma as duas podem variar independentemente.

 

Builder

Separa a construção de um objeto complexo de sua representação. Dessa forma, o mesmo processo de criação pode criar representações diferentes.

 

Business Delegate

Oculta do cliente a complexidade da comunicação remota com os componentes de serviços da camada de negócios.

 

Composite

Compõe objetos para representar hierarquias de parte-todo. O Composite é constituído pela composição de objetos similares a ele e deixa a aplicação tratar objetos individuais e composições de objetos uniformemente.

 

Composite View

Constrói a camada de visualização de maneira modular, com partes menores que são combinadas para uma formação mais complexa.

 

Context Object

Evita o uso de informações específicas do protocolo fora do contexto relevante.

 

Data Access Object

Encapsula o acesso e a manipulação dos dados em uma camada separada.

 

Factory Method

Define uma interface para a criação dos objetos, mas deixa as subclasses decidirem qual classe instanciar.

 

Flyweight

Utiliza um compartilhamento para suportar um número grande de objetos de granularidade fina eficientemente.

 

Intercepting Filter

Intercepta e manipula uma requisição antes e depois de ser processada.

 

Mediator

Define um objeto que encapsula as interações de um conjunto de objetos. O Mediator promove baixo acoplamento e gerencia as colaborações entre os objetos.

 

Proxy

Provê um representante de um objeto para controlar o acesso a ele e realizar outras operações.

 

Service Activator

Invoca serviços de maneira assíncrona.

 

Service Locator

Localiza componentes e serviços de negócio de maneira uniforme e transparente.

 

Session Facade

Provê uma interface unificada para um conjunto de interfaces em um subsistema a ser exposta a clientes remotos.

 

Singleton

Garante que a classe terá apenas um número fixo (normalmente um) de instâncias e provê um ponto de acesso global a essa instância.

 

Template Method

Define um esqueleto de um algoritmo, adiando alguns passos para as subclasses. O Template Method deixa as subclasses redefinirem certos passos de um algoritmo sem mudar a estrutura.

 

Transfer Object

Permite a transferência de vários dados por uma camada.

 

Transfer Object Assembler

Agrega vários Transfer Objects de vários componentes de negócio.

 

View Helper

Separa a visualização da lógica de processamento.

 

Web Service Broker

Provê acesso a um ou mais serviços utilizando XML e protocolos WEB.

 

Conclusão

Nesta parte descrevemos o que é um padrão de projeto, quais são seus benefícios e relacionamos o catálogo que será utilizado nas outras partes do artigo.

 

Na próxima parte, descreveremos o padrão de projeto Abstract Factory com exemplos práticos, como e quando ele pode ser utilizado para melhorar o desenvolvimento de sua aplicação corporativa e as conseqüências do seu uso.

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?