Padrões Estruturais em Delphi

[rotulo-mentoring/] [lead-mentoring]Padrões de projeto são soluções prontas e reutilizáveis para problemas recorrentes da orientação a objetos, entre eles os principais são: forte acoplamento entre classes, dificuldade de reutilização de componentes, falta de modularização, duplicação de código e altos custos com manutenção. Os padrões de projeto são apresentados no livro “Design Patterns: Elements of Reusable Object-Oriented Software”, dos autores E. Gamma, R. Helm, R. Johnson e J. Vlissides, mais conhecidos como Padrões GoF (Gang of Four), ver referências bibliográficas na sessão Links. No artigo da edição 152 da Revista ClubeDelphi foram abordados os padrões da categoria criacionais, incluindo Abstract Factory, Factory Method, Singleton e Builder, que tinham por finalidade resolver problemas com forte acoplamento de classes devido a criação de objetos concretos. Neste artigo, vamos abordar alguns padrões do grupo Estrutural, que têm por finalidade mostrar como formar objetos a partir de funcionalidades de outros objetos, seja por herança de abstrações, associações e composição. Os padrões apresentados neste artigo são o Adapter, Bridge, Composite, Decorator e Façade.

Em que situação o tema é útil
Padrões de projeto estruturais são úteis para criar softwares mais fáceis de serem mantidos, evoluídos, promovendo reutilização de código, uso de boas práticas de programação orientada a objetos, redução de custos com manutenção, já que permitem que alterações em um determinado sistema não quebrem outras funcionalidades, reduzindo a dependência entre classes, através do uso exaustivo de abstrações. Dos padrões tratados neste artigo, o Adapter serve para permitir a comunicação entre duas classes com interfaces distintas; Bridge serve para separar totalmente a interface de um objeto de sua implementação concreta; Composite permite criar composições de objetos; Decorator permite adicionar funcionalidades a um objeto sem usar herança estática, usando herança de “caixa-preta”, através da implementação por delegação; Façade ajuda a tornar um subsistema de classes mais fácil de utilizar. Como na edição anterior, primeiramente será apresentada uma descrição formal de cada padrão segundo GoF, depois um exemplo prático em Delphi. [/lead-mentoring]

Adapter

A intenção do padrão Adapter, também conhecido como Wrapper, é converter a interface de uma classe em outra interface esperada pelos clientes. Permite que classes trabalhem em conjunto, pois de outra forma não poderiam, devido ao fato de terem interfaces incompatíveis. O padrão pode ser usado quando se quiser usar uma classe existente, mas sua interface não corresponder à interface que necessita; ou quando quiser criar uma classe reutilizável que coopere com classes não relacionadas ou não previstas, ou seja, classes que não necessariamente tenham interfaces compatíveis; você precisa usar várias subclasses existentes, porém, quando for impraticável adaptar essas interfaces criando subclasses para cada uma. O padrão traz alguns benefícios. Um adaptador de classe adapta Adaptee a Target através do uso efetivo de uma classe Adapter concreta, com isso, permite a Adapter substituir algum comportamento do Adaptee, uma vez que Adapter é uma subclasse de Adaptee. Um adaptador de objeto permite que um único Adapter trabalhe com muitos Adaptees. O Adapter também pode acrescentar funcionalidades a todos os Adaptees de uma só vez.

Os participantes do padrão de projeto são:

· Target – define a interface específica do domínio que o Client usa;

· Client – colabora com objetos compatíveis com a interface de Target;

· Adaptee – define uma interface existente que necessita ser adaptada;

· Adapter – adapta a interface do Adaptee à interface do Target;

Para entender melhor o padrão Adapter, vamos recorrer a alguns objetos do mundo real. Por exemplo, digamos que quiséssemos conectar nosso notebook em uma tomada para recarregar sua bateria. Ao entrar em uma sala e encontrar um ponto livre, reparamos que a tomada fêmea segue o novo padrão brasileiro NBR 14136, enquanto nosso notebook tem um cabo com plug macho no padrão norte americano NEMA 5. Ou seja, estamos com problemas para conectar dois objetos, pois eles possuem interfaces incompatíveis. A solução para este problema no mundo real é fácil de ser resolvida, precisamos de um Adaptador, ou Adapter. Ele vai se encarregar de converter o a interface do Adaptee (o plug do nosso notebook) em um formato que o Target entenda (o alvo, a tomada, onde realmente queremos conectar). A Figura 1 mostra um exemplo de como seriam nossos personagens do padrão de projeto em objetos do mundo real.

Figura 1. Adaptador no mundo real conecta duas interfaces distintas

No mundo orientado a objetos, um Adapter é frequentemente encontrado em muitas situações. No Delphi, por exemplo, temos dezenas de aplicações deste padrão. Vamos observar a arquitetura do novo DataSnap. No modelo antigo do DataSnap (e primeiras versões do MIDAS), tínhamos um componente de conexão remoto para cada tipo de protocolo que nosso servidor de aplicação pudesse trabalhar. Por exemplo, um DCOMConnection era utilizado no cliente para conectar a um servidor DCOM, MTS ou COM+. A partir do Delphi 6, com o suporte a Web Services, foi possível utilizar um SOAPConnection para conectar em um servidor de aplicação baseado em SOAP (Simple Object Access Protocol). E poderíamos citar outros tipos de conexão, como CorbaConnection, WebConnection, SocketConnection e etc. Um ClientDataSet pode então se conectar a qualquer um desses componentes concretos para obter dados de diferentes tipos de servidores, independente do protocolo que usem. Para isso, basta aponta-los para a propriedade RemoteServer de ClientDataSet ("

[...] continue lendo...