Consulta Rpida

Design Patterns Delphi

Jos Emdio Francelino 2013

Sumrio
Sobre autor ................................................................. 3 Introduo .................................................................. 3 Origens .......................................................................4 Afinal, o que Design Pattern? ......................................5 Por que usar ? .............................................................6 Detectando um bom Design Pattern................................7 Quando usar ? .............................................................7 Tipos ..........................................................................8 Componentes ..............................................................9 Qualidades ................................................................ 11 Design Pattern versus Framework ................................ 12 Anti-Patterns ............................................................. 13 Exemplos em Delphi ................................................... 22 A Ferramenta ModelMaker 4.01.................................... 30 A Ferramenta DP++ ................................................... 32 Consideraes Finais................................................... 35 Webliografia .............................................................. 35 Agradecimentos ............... Erro! Indicador no definido.

Sobre autor
Jos Emdio Francelino, desenvolve em Delphi, atualmente em JAVA para Androide e BlackBerry e Interfaces em HTML5+CSS usando Javascript.

Introduo
Desenvolver software no tarefa das mais fceis. Um dos fatores que gera esta dificuldade que muitas vezes o entendimento do problema no est muito claro. Alm disso, h uma escassez grande na documentao dos problemas e nas solues encontradas para solucion-los. Com isso, problemas que muitas vezes se repetem, geram esforos adicionais para a implementao de suas solues. As tentativas de reuso das boas solues e do acmulo de experincias sobre determinados problemas so, na maioria das vezes, iniciativas isoladas de alguns desenvolvedores. O uso dos design patterns vem preencher esta lacuna que existe, tornando-se um mecanismo eficiente no compartilhamento de conhecimento entre os desenvolvedores (principalmente hoje com o uso da Internet). A meta a criao de uma linguagem comum, que permita uma comunicao efetiva no que se refere a troca de experincias sobre problemas e suas solues. Desta forma, solues que se aplicaram a situaes particulares, podem ser novamente aplicadas em situaes semelhantes por outros desenvolvedores. Codificando estas solues, estamos tambm capturando o conhecimento do sistema, indo ao encontro das necessidades dos usurios. A criao de um repositrio de design patterns ajuda tanto ao desenvolvedor experiente quanto ao novato, no reconhecimento de situaes nas

quais o reuso poderia ocorrer. O foco principal no nem tanto tecnolgico, mas sim o de criar uma cultura de catalogao de experincias e solues para apoiar o desenvolvimento de software.

Origens
Os Design Patterns originam-se no final dos anos 80 quando Ward Cunningham e Kent Beck desenvolveram um conjunto de padres para serem aplicados no desenvolvimentos de interfaces do usurio elegantes em Smalltalk. No mesmo perodo, Jim Coplien estava desenvolvendo um catlogo de padres C++ chamados idiomas. Enquanto isso, Erich Gamma estava trabalhando em sua tese de doutorado sobre desenvolvimento de software orientado a objeto, e reconheceu a importncia de acumular explicitamente as estruturas de projetos que se repetiam com frequncia. Essas e outras pessoas intensificaram suas discusses em uma srie de workshops do OOPSLA organizado em 1991 por Bruce Anderson, e em 1993 a primeira verso de um catlogo de padres estava esboada. Todas estas atividades foram influenciadas pelos trabalhos de Christopher Alexander, um arquiteto urbano que associou o termo "pattern" s repetices de formas em arquitetura. Ele argumentava que os mtodos de arquiteturas no atendiam s reais necessidades dos indivduos e da sociedade. Ele queria criar estruturas que melhorassem a qualidade de vida das pessoas. Era qualidade serio o principal objetivo a ser atingido com o uso dos padres.

Patterns tambm tm sido usados nos mais diferentes domnios, abrangendo o desde o desenvolvimento software at o uso em Arquitetura e Educao.

Afinal, o que Design Pattern?

Poderamos dizer, de forma sucinta, que um design pattern " uma soluo para um problema em um determinado contexto", onde: Contexto se refere ao conjunto de situaes que se repetem, nas quais o design pattern pode ser aplicado; Problema se refere ao conjunto de "foras" objetivos e limitaes que ocorrem dentro do contexto; Soluo uma estrutura formal para ser aplicada na resoluo do problema. A soluo tenta capturar a essncia do problema, a fim de que outros desenvolvedores a entendam, e possam fazer uso dela em situaes similares. Esta definio pode ser escrita de uma outra maneira: " uma relao ternria entre um determinado contexto, um determinado conjunto de foras (objetivos e restries) que ocorrem repetidamente neste contexto, e uma determinada configurao de software que permite que estas foras sejam resolvidas." Em termos de orientao a objetos, design patterns identificam classes, instncias, seus papis, colaboraes e a distribuio de responsabilidades. Seriam, ento, descries de classes e objetos que se comunicam, que so

implementados a fim de solucionar um problema comum em um contexto especfico. O design pattern faz mais do que identificar a soluo, ele explica porque a soluo necessria.

Por que usar ?

Design patterns tm vrios usos no processo desenvolvimento de software orientado a objetos: de

Formam um vocabulrio comum que permite uma melhor comunicao entre os desenvolvedores, uma documentao mais completa e uma melhor explorao das alternativas de projeto. Reduz a complexidade do sistema atravs da definio de abstraes que esto acima das classes e instncias. Um bom conjunto de padres aumenta muito a qualidade do programa; Constituem uma base de experincias reutilizveis para a construo de software. Funcionam como peas na construo de projetos de software mais complexos; podem ser considerados como micro-arquiteturas que contribuem para arquitetura geral do sistema; Reduzem o tempo de aprendizado de uma determinada biblioteca de classes. Isto fundamental para o aprendizado dos desenvolvedores novatos; Quantos mais cedo so usados, menos ser retrabalho em etapas mais avanadas do projeto. o

Detectando um bom Design Pattern

Nem toda soluo, algoritmo ou prtica constitui um padro. Embora possa parecer que possua todos os requisitos bsicos para ser um padro, ele no pode ser considerado como tal at que o fenmeno da repetio seja verificado (Em geral, aplicada a regra de trs 3 situaes comprovadas em que o padro se aplica). Um bom design pattern tem as seguintes caractersticas: Resolve o problema, e no apenas indica princpios e estratgias; um conceito provado, no constituindo apenas uma hiptese ou uma especulao; A soluo no bvia; No apenas descreve os mdulos, mas como eles se relacionam, atravs de estruturas e mecanismos do sistema. Tem um significante componente humano : atinge a qualidade quer seja na clareza, na utilidade, na documentao.

Quando usar ?

Devemos usar design patterns em solues que se repetem com variaes. No faz sentido o reuso, se o problema s aparece em um determinado contexto. Em geral, os design patterns representam solues que requerem vrios passos. Se o nmero de passos for pequeno, no h a necessidade de usarmos padres. Design patterns se aplicam muito bem em situaes em que o desenvolvedor est mais interessado na existncia de uma soluo do que na sua total implementao. Isto ocorre, na maior parte das vezes, quando o domnio do problema o foco da questo.

Tipos
A expresso design pattern muitas vezes se refere a qualquer padro relacionado a arquitetura, projeto e implementao de software. Os autores do livro Patterns of Software Architecture [POSA96] definem 3 tipos de padres; Padro de Arquitetura (Architectural Pattern) : representa um esquema de organizao estrutural dos sistemas. Fornece um conjunto de subsistemas prdefinidos, especifica suas responsabilidades, e inclui regras para organizar os relacionamentos entre eles. Se preocupam com o sistema como um todo, seus componentes macro e suas propriedades globais. Suas implicaes afetam a estrutura e a organizao do sistema inteiro. Design Pattern : prov um esquema de refinamento dos subsistemas e componentes do software, e dos relacionamentos entre eles. Descrevem situaes que se repetem, e solues para problemas em contextos

especficos. No afetam a estrutura global do sistema. Idioma (Idiom) : um padro de baixo nvel, especfico a uma linguagem de programao. Um idioma implementa aspectos dos componentes e de suas relaes entre si, utilizando uma determinada linguagem de programao. Gamma prope um modo de categorizao dos design patterns, definindo famlias de padres relacionados: Creational inicializao patterns de : abrange objetos a configurao e e classes; e a

Structural patterns : lida com as interfaces implementao das classes e dos objetos;

Behavioral : lida com as interaes dinmicas entre grupos de classes o objetos.

Componentes
Existem diversas formas de escrevermos um design pattern. No entanto, independente do formato, os alguns componentes devem ser facilmente reconhecidos quando da leitura de um design pattern. A forma aqui descrita conhecida como forma cannica. Nome e Classificao - Deve expressar a essncia do padro. Um bom nome vital, pois vai se tornar parte do vocabulrio do projeto. Propsito - O que faz o design pattern ? Qual o problema que se prope a atacar ? Qual os objetivos que deseja alcanar?

Motivao - Descreve o cenrio no qual se aplica, todas as foras que esto presentes, as classes e os objetos relacionados. Aplicabilidade - Quais so as situaes na qual o design pattern pode ser aplicado ? Como reconhecer estas situaes ? Participantes - Descreve as classes e/ou objetos que participam no design pattern e suas responsabilidades. Colaboraes - Descreve como os participantes colaboram entre si para realizar suas responsabilidades. Assim, a soluo descreve no somente a estruturas estticas, mas tambm a dinmica comportamental dos objetos e classes. Diagrama - Representao grfica do padro utilizando a tcnica de modelagem de objetos. Consequncias - Quais os resultados obtidos com a aplicao do design pattern.? O que foi resolvido, o que no foi resolvido e que design patterns podem ser aplicados neste momento? Implementao - Quais so as dicas, os macetes e as tcnicas que devem estar claras quando da implementao do padro. H questes relativas a um linguagem especfica. Exemplos - Exemplos de sistemas reais, onde o design pattern foi aplicado e que transformaes ocorreram dentro de cada contexto. Design Patterns afins Quais design patterns tm relao com este design pattern ? Quais so as diferenas

importantes ? Com que outros padres este deve ser usado ?

Qualidades
Design Pattern pode ser visto como extenso da definio de classes. Em orientao a objetos, as classes tm dois aspectos bsicos, anlogos aos design patterns : Externo, a viso do problema : descries das propriedades, responsabilidades, capacidades e servios prestados ao software ou ao ambiente externo; Interno, a viso da soluo: descries estticas e dinmicas, limitaes, e relacionamentos entre os componentes, colaboradores, ajudantes, cada um apenas com uma viso externa incompleta. Design Patterns aumentam a expressividade e o nvel de descrio suportados pela orientao a objetos. Inversamente, os conceitos de OO podem ser aplicados aos design patterns: Encapsulamento e Abstrao Cada design pattern engloba um problema em um determinado contexto e a sua soluo, com limites bem definidos entre o espao do problema e da soluo. Tambm corresponde a uma abstrao que abrange conhecimento e experincias sobre o domnio da aplicao. Extensibilidade e Adaptabilidade

Cada design pattern deve ser extensvel para que outros design patterns possam mold-lo a fim de resolver um problema mais amplo. Deve ser tambm adaptvel para que sua soluo possa servir em uma vasta gama de implementaes. Gerao e Composio Cada padro, uma vez aplicado, gera como consequncia um contexto inicial de um ou mais design patterns. Estes podero ser aplicados em conjunto, com o objetivo de alcanar uma soluo global e completa. Equilbrio Os padres devem procurar atingir um equilbrio entre suas foras e restries. Deve-se minimizar os conflitos dentro do espao de soluo do problema,e dar um porqu para cada passo ou regra dentro do design pattern

Design Pattern versus Framework

Um conceito estreitamente relacionado com o de orientao a objetos e o de design patterns o de framework. Um framework consiste em uma arquitetura concreta reutilizvel que prov estruturas genricas para uma famlia de softwares. Um framework pode ser adaptado para atender vrias necessidades dentro de um determinado domnio. Ele no constitui uma aplicao completa, visto que no tem toda a funcionalidade especfica da aplicao. Esta pode ser construda, adicionando funcionalidades a um ou mais frameworks,

atravs do mecanismo de heranas e de instanciaes dos seus componentes. Um framework difere das bibliotecas de programao porque possui um fluxo inverso de controle, isto , ele que determina quais objetos e mtodos devem ser usados quando da ocorrncia de eventos. Ao contrrio dos frameworks, os design patterns permitem o reuso de micro-arquiteturas abstratas sem uma implementao concreta. Os frameworks so implementados em uma linguagem de programao, enquanto que os padres constituem formas de us-las. Em geral, os design patterns so menos especializados que os frameworks, podendo ser aplicados em um nmero maior de aplicaes. Eles ajudam na definico e na documentao de um framework. Normalmente, frameworks maduros englobam dezenas de design patterns.

Anti-Patterns
O que AntiPattern? AntiPattern representa um dos conceitos mais recentes em uma srie de mudanas revolucionrias na cincia da computao e na engenharia de software. O desenvolvimento de Design Patterns tm favorecido o desenvolvimento software atravs de uma das mais efetivas orientaes disponveis. Podemos assumir que a inteno de se desenvolver um software a de fornecer uma soluo para algum problema em particular. Mas, essas solues algumas vezes nos conduzem a uma situao que so mais problemticas do que o prprio problema inicial. De acordo com J. Johnson

em "Creating Chaos"(American Programmer, Julho 1995), por exemplo, uma pesquisa com centenas de projetos de desenvolvimentos de software indica que cinco de seis projetos so considerados mal sucedidos, a tera parte dos projetos so cancelados e os projetos restantes que so entregues gastam o dobro do oramento e levam o dobro do tempo para serem desenvolvidos do que o inicialmente planejado. Essas falhas repetidas, ou "solues negativas", so valiosas quando nos fornecem o conhecimento daquilo que no funciona, e o por qu. Tal estudo classificado como AntiPatterns. Design Patterns versus AntiPatterns. Um Design Patterns enfoca um problema de software em particular, mostrando uma discusso detalhada de como esse problema pode ser encaixado dentro de um contexto que descreve as circunstncias sob as quais o problema ocorre e os seus fatores de motivao que denominam-se foras. Tambm descreve como essas foras devem ser resolvidas ou balanceadas dentro de um escopo do contexto, fornecendo assim uma soluo que pode levar a resultados positivos ou benefcios, solues relacionadas ou pode levar a foras ruins denominadas conseqncias. Ao contrrio de Design Patterns, Antipatterns comea com uma "soluo ruim" j existente, possivelmente resultada de uma inexperincia em se resolver um tipo de problema em particular ou na aplicao de um Design Patterns em um contexto errado. O AntiPatterns ento amplifica essa soluo ruim de modo a permitir o reconhecimento da situao problemtica, seus sintomas e conseqncias. O Antipatterns ento apresenta uma nova soluo que refatora o sistema visando maximizar os benefcios e

minimizar as conseqncias. Antipatterns comea com uma soluo problemtica. Dessa soluo, uma discusso das causas primrias registra como essa soluo foi uma tentativa incorreta de se resolver os fatores de uma coleo de problemas dentro de um contexto. Essa convergncia de uma situao concreta para uma mais abstrata que descreve os fatores subjacentes ou foras, um componente chave de se compreender como e por que o problema existe. Essa abstrao composta de sintomas e conseqncias , similares ao contexto e foras no Design Patterns, mas os quais documentam claramente as implicaes da soluo problemtica. Essas sintomas documentados de fundamental importncia para se diagnosticar e reconhecer uma soluo problemtica especfica, ou, Antipatterns. Quando o Antipatterns estiver corretamente identificado, sua soluo refatorada usada para se obter uma convergncia melhor dos fatores subjacentes que leva a uma melhor compreenso do problema e a um mtodo efetivo de resolver a soluo problemtica. Por isso, Antipatterns so uma extenso natural de Design Patterns. Em vez de codificar pura Cincia da Computao, Antipatterns enfoca na crescente seleo de falhas de software repetidas na inteno compreender, prevenir e recuperar-se delas. Para o desenvolvedor, Antipatterns so uma nova ferramenta que interliga os conceitos de arquitetura de software com a implementao no mundo real. Eles so usados para representar um aspecto comum, os problemas que a maioria do desenvolvedores de software enfrentam e compartilhar o conhecimento aprendido da experincia de outros desenvolvedores. Apenas com a compreenso das causas de um Antipattern os desenvolvedores podem assegurar que essa soluo problemtica no vai ser continuamente repetida dentro da organizao.

Componentes do AntiPattern O uso de templates define a diferena entre Design Patterns e Antipatterns e outras formas de discusso tcnica. Esses Templates asseguram que questes importantes sejam respondidas sobre cada Patterns em uma linguagem, catlogo ou sistema de Patterns. O template completo de Antipatterns fornece informaes abrangentes sobre uma classe particular de problemas, incluindo uma discusso de seu background, sua forma geral, sintomas ou conseqncias, fonte de causas, sua soluo refatorada e um exemplo detalhando como o refatoramento do processo pode ser aplicado para criar uma soluo eficiente. As solues incluem o seguinte:

Forma Geral: Geralmente inclui um diagrama que identifica as caractersticas gerais do Antipattern. A soluo refatorada resolve o Antipatterns proposto por essa seo. Sintomas: Fornece os indicadores que sugerem a existncia de um Antipattern numa situao especfica. Eles se manifestam atravs de comentrios de indivduos, da observao da estrutura do software, nas mudanas organizacionais, na falta de habilidade de se atingir uma meta, etc. Causas Tpicas: Essa seo descreve as causas subjacentes que leva a um Antipattern especfico. Excees Conhecidas: O comportamento de um Antipattern pode no estar errado. Existem ocasies especficas quando isto acontece. Essa seo identifica brevemente a primeira exceo

para

cada

Antipattern.

Conseqncias: Essa seo descreve os efeitos prejudiciais do Antipattern, incluindo ainda o dano contnuo causado pelo Antipattern como tambm o resultado se medidas de correo no forem tomadas. Soluo Refatorada: Essa seo explica uma soluo refatorada que resolve as foras no Antipattern identificadas na seo Forma Geral. Essa soluo descrita sem as variaes indicadas pela seo Excees Conhecidas. A soluo pode ser estruturada em passos. Aspectos do Antipattern O Antipatern pode ser visto em trs aspectos principais: a do desnvolvedor de software, do arquiteto de software e do gerente de software. Os Antipatterns de desenvolvimento descreve situaes encontradas pelo programador quando est solucionando problemas de programao. Antipattern Arquiteturais enfoca em problemas comuns na estrutura do sistema, suas conseqncias e solues. Muitos problemas srios sem soluo em sistemas de software ocorrem dessa perspectiva. Antipatterns de gerenciamento descreve solues e problemas comuns devidos a organizao do software. Antipatterns de gerenciamento afetam pessoas que desempenham um papel no software, e suas solues afetam diretamente o sucesso tcnico do projeto. Antipattern de Desenvolvimento A primeira exposio em Antipatterns de desenvolvimento de software foi atravs da apresentao de Mike Akroyd, um consultor que presta servios para a Motorola e outras grandes firmas [Akroyd 96]. O Akroyd Antipatterns define

problemas clssicos em projetos de software orientados a objetos. Uma caracterstica atrativa de seus Antipatterns a incluso de solues refatoradas, que nos d a possibilidade de no somente apontar o problema, como nos ajudar a sair dele. Um Antipattern adequado define uma migrao (ou refatoramento) de uma soluo ruim, para uma soluo boa. O Antipattern que descreve somente a soluo negativa denominado de PseudoAntipattern. Um objetivo importante no desenvolvimento de Antipatterns descrever formas de refatoramento de software que sejam teis. Refatoramento de software (Software Refactoring) uma forma de modificao de cdigo, visando melhorar o sua estrutura para suportar expanses e manutenes. Na maioria dos casos, a meta transformar o cdigo sem causar impacto de correo. A estrutura resultante no precisa se assemelhar com a estrutura planejada inicialmente. A estrutura muda devido ao fato que os programadores aprendem novas restries e facilidades que alteram o contexto da soluo codificada. Alguns exemplos de Antipatterns de Desenvolvimento: AntiPattern: Continuous Obsolescence Sinopse: A distribuio de tecnologias na era internet supera a nossa capacidade de manter tecnologias sincronizadas. da outras

Soluo Refatorada: Dependa de e interfaces que voc controla. fornecem estabilidades. Cut and Paste Programing

tecnologias estveis Sistemas abertos

Sinopse: Reuso de cdigo copiando somente as declaraes da fonte, leva a problemas de manuteno significativos. Soluo Refatorada: O reuso Black Box reduz o custo de manuteno fornecendo uma fonte de cdigo comum, testes e documentao para vrios reusos. Walking Through a Mine Field Sinopse: A tecnologia do software muito robusta que as pessoas imaginam. Bugs otencialmentes catastrficos . menos so

Soluo Refatorada: Investimentos adequados no teste e inspeo do software so necessrios para reduzir a frequncia e densidade dos defeitos.

Antipattern de Arquitetura A arquitetura de software difere da programao em vrias formas. A arquitetura cuida do impacto das decises no custo do projeto. Enfoca trs aspectos do projeto de software: Particionamento, particionamento funcional dos mdulos; Interfaces, interface entre os mdulos do software; Conexes, caractersticas da tecnologia usada na implementao das interfaces das conexes entre os

mdulos

do

software.

Os Antipatterns de Arquitetura enfoca problemas e erros comuns na criao, implementao e gerenciamento da arquitetura. Falta de atributos comuns entre sistemas em termos de projeto e tecnologia a causa de inabilidade para fornecer interoperabilidade e reuso entre sistemas relacionados. Melhorando o planejamento de arquitetura da empresa pode ajudar a alinhar o desenvolvimento de sistemas. Alguns exemplos de Antipatterns de Arquitetura: Spaghetti Code Sinopse: difcil de extender e otimizar o cdigo de uma estrutura de software ad hoc. Soluo Refatorada: O refatoramento de cdigo freqente pode melhorar a estrutura do software, suporte manuteno e desenvolvimento iterativo. Stovepipe Enterprise Sinopse: Arquiteturas de software com falta de cordenao leva a falta de adaptabilidade,reuso e interoperabilidade. Soluo Refatorada: Usar um planejamento de arquitetura de software para coordenar convenes do sistema, reuso e interoperabilidade. Stovepipe System Sinopse: Solues de integrao ad hoc e falta de abstrao levam a arquiteturas frgeis e

difceis de fazer manuteno. Soluo Refatorada: Uso adequado de abstraes e metadados levam a sistemas adaptveis. Antipatterns de gerenciamento Na profisso de engenharia moderna, mais que metade do trabalho envolve comunicao humana e questes pessoais. AntiPatterns de gerenciamento identifica alguns cenrios chaves aonde essas questes so destrutivas aos processos de software. O propsito do AntiPatterns de gerenciamento construir novas precaues que nos leve a melhorar nosso sucesso. AntiPattern de gerenciamento descreve como os projetos de software so prejudicados por questes pessoais, processos, recursos e relacionamento externo. O Antipattern tambm descreve alguma solues efetivas para esses problemas Alguns exemplos de Antipatterns de Gerenciamento: Email is dangerous Sinopose: Email til, mas um meio voltil de comunicao. Soluo Refatorada: Evite usar email para trocar mensagens controversiais e confrontamentais. Smoke and Mirrors Sinopse: Usurios finais assumem incorretamente que uma demonstrao frgil tem capacidade de entrar em operao.

Soluo Refatorada: A prtica de ticas adequadas importante para gerenciar expectativas, riscos, responsabilidades e conseqncias em vendas na rea de computao e situaes de marketing.

Exemplos em Delphi
A fim de tornar mais compreensvel e prtico o conceito de Design Patterns, vamos apresentar alguns exemplos de padres bsico descritos no livro "Design Patterns: Elements of Reusable OO Software", implementando tais padres numas das ferramentas mais conhecidas atualmente, o Borland Delphi. Alguns dos padres descritos neste livro so: SingleTon Mediator Abstract Factory

SingleTon "Garanta que uma classe possua uma nica instncia, e provenha uma forma de acesso global a esta instncia" Existem vrios exemplos de classes de Delphi que utilizam este padro, tais como: TApplication, TScreen, TClipboard. Este padro til quando queremos um nico objeto global para o seu sistema.

Outros formas de utilizao prev o uso de tratamentos globais de exceo, segurana da aplicao ou um nico ponto de interface com outro sistema. Uma cdigo simples para o SingleTon seria:

unit Singletn; interface uses SysUtils, WinTypes, WinProcs, Messages, Classes, Graphics, Controls, Forms, Dialogs; type TCSingleton = class(TComponent) public constructor Create(AOwner: TComponent); override; destructor Destroy; override; end;

Type TOSingleton = class(TObject) Public constructor Create; destructor Destroy; override; end;

var Global_CSingleton: TCSingleton; Global_OSingleton: TOSingleton;

procedure Register; implementation procedure Register; begin RegisterComponents('Design Patterns', [TCSingleton]); end;{ TCSingleton }

constructor TCSingleton.Create(AOwner: TComponent); begin if Global_CSingleton <> nil then Abort Else Begin inherited Create(AOwner); Global_CSingleton := Self; end; end;

destructor TCSingleton.Destroy; begin if Global_CSingleton = Self then Global_CSingleton := nil; inherited Destroy; end;{ TOSingleton }

constructor TOSingleton.Create; begin if Global_OSingleton <> nil then Abort else Global_OSingleton := Self; end;

destructor TOSingleton.Destroy; begin if Global_OSingleton = Self then Global_OSingleton := nil; inherited Destroy; end;

procedure FreeGlobalObjects; far; begin if Global_CSingleton <> nil then Global_CSingleton.Free;

if Global_OSingleton <> nil then Global_OSingleton.Free; end;

begin AddExitProc(FreeGlobalObjects); end. Mediator "Provenha uma forma centralizada de para tratar interaes entre objetos que tenham interface padronizada, mas complexa." Este padro nos auxilia a desacoplar classes. Bons momentos para utilizar este padro ocorrem quando: um conjunto de objetos se comunicam de forma bem definida, mas de forma complexa, resultado numa organizao confusa reusar algum objeto difcil devido as suas interdependncias um comportamento que distribudo entre muitas classes deve ser customizado sem subclasses excessivas

Classes Mediator em geral tambm so SingleTon. Alguns exemplos de Mediators em Delphi so: TDatabase, Network Router, Internet Server.

Abstract Factory "Provenha uma interface para criao de instncias de uma classe relacionada ou dependente sem especificar suas classes concretas" Este padro idealmente utilizado quando queremos isolar a aplicao da implementao das classes concretas. Por exemplo, se queremos sobrepor a VCL (Visual Component Library) do Delphi para aplicao de ambos 16 e 32 bits, devemos iniciar com uma fbrica abstrata como base. Este exemplo de implementao utiliza uma fbrica abstrata e duas fbricas concretas para implementar diferentes estilos de componentes de interface com o usurio. TOAbstractFactory uma classe SingleTon, pois ns geralmente desejamos que uma fbrica seja usada para toda a aplicao. TORedFactory e TOBlueFactory sobrepe a interface abstrata para suportar os diferentes estilos necessrios.

TOAbstractFactory = class(TObject) public constructor Create; destructor Destroy; override; { abstract widget constructors } function CreateSpeedButton(AOwner: TComponent): TSpeedButton; virtual; abstract;

function CreateEdit(AOwner: TComponent): TEdit; virtual; abstract; function CreateLabel(AOwner: TComponent): TLabel; virtual; abstract; end;

TORedFactory = class(TOAbstractFactory) public { concrete widget constructors } function CreateSpeedButton(AOwner: TComponent): TSpeedButton; override; function CreateEdit(AOwner: TComponent): TEdit; override; function CreateLabel(AOwner: TComponent): TLabel; override; end;

TOBlueFactory = class(TOAbstractFactory) public { concrete widget constructors } function CreateSpeedButton(AOwner: TComponent): TSpeedButton; override; function CreateEdit(AOwner: TComponent): TEdit; override; function CreateLabel(AOwner: TComponent): TLabel; override; end;

Exemplo de Aplicao: MUD No contexto de um jogo multiusurio, baseado em threads, demonstraremos o uso dos trs padres apresentados anteriormente.

O jogo uma simulao de um Multi-User Dialog (MUD) e mostra as interaes entre diferentes personagens do jogo, que de forma a simplificar, estaremos utilizando apenas guerreiros e mostros. Como um modelo bsico de classes do MUD temos: Notar que dadas as caractersticas do jogo, algumas padres so observados: Como o jogo baseado em tempo real e no em "turnos", ento existir uma classe Mediator para coordenar todas as aes Este coordenao deve ser nica, independente do nmero de participantes. Ento deveremos usar o padro SingleTon Existe um nmero arbitrrio de participantes (guerreiros ou mostros), entretanto todos pertencente a uma ou mais classes padres. Ento devero existir a AbstractFactory. Neste exemplo, a classe TCombatDirector a intermediadora do MUD. de sua responsabilidade todo o clculo matemtico e ordenao necessrios para a simulao de combate. Os mtodos da classe TCombatDiretor que so pblicos, sendo chamados do mundo externo so: {pega as instncias da classe} class function Instance: TcombatDirector; {A torna um singleTon}

{inicializa o cenrio Character (ch) vs Moster (ms)} procedure StartBattle(ch,mo:Integer);

{Pra todas as threads} procedure StopBattle;

O que demonstra como esta classe interage com os objetos do sistema.

A Ferramenta ModelMaker 4.01

ModelMaker uma ferramenta CASE que se prope, alm de gerar cdigos propriamente em Delphi, utilizar o conceito de Design Patterns como diferencial do seu produto. O ModelMaker possui as funcionalidades de: Modelagem de classes de forma grfica Modelagem de relacionamento entre classes Gerao de cdigo para diagrama de classes Reutilizao de cdigo atravs de herana de classes e macros Permite fazer reengenharia inversa de qualquer unit

Alm de possui uma srie de Design Patterns implementados que podem ser utilizados diretamente. Durante a criao e especificao de uma classe, podemos aplicar estes padres pr-definidos, embutindo os mtodos

e propriedades necessrias de forma automtica. permitido tambm a criao de seus prprios padres.

Formas de Manipulao Existem trs telas principais que devem ser utilizadas para manipulao dos dados: a tela de visualizao em rvore, tela de visualizao de propriedades e mtodos, e finalmente a tela de manipulao de cdigo.

A criao de propriedades tambm possui uma tela especfica que dispensa conhecimentos da linguagem.

Anlise Geral Em geral podemos destacar aspectos positivos e negativos encontrados na ferramenta.

Aspectos Favorveis: A ferramenta possui alto grau de visualizao de informaes atravs de diversos nveis de interface. A interface similar em funcionalidade ao SmallTalk possvel gerar cdigo, a princpio razoavelmente bem. Principalmente se forem aplicados os design patterns Muitos padres j foram implementados e prdefinidos na ferramenta, entretanto a possibilidade de criar o seu prprio padro muito til para padronizao de grandes empresas.

Deficincias: A ferramenta um tanto burocrtica para a sua utilizao. Entretanto isso no difere muito do que em geral uma ferramenta CASE, com todos os seus procedimentos bastante rgidos a fim de forar a documentao A ferramenta tenta substituir de forma inferior a interface grfica de programao do Delphi. Seus recursos de localizao de texto, identificador de sintaxe, etc, citados no Delphi como pontos fortes, no ModelMaker no so to bem utilizados. Foram encontrados alguns bugs na verso 4.01. Erros um tanto inaceitveis, como na alocao do design pattern Adapter a uma classe. Entretanto o pattern alocado foi na verdade o SingleTon.

A Ferramenta DP++

DP++ uma ferramenta para deteco de Design Patterns em sistemas escritos em C++. Ela automatiza a deteco, identificao, classificao e apresenta os Design Patterns e as estruturas de classes do programa em vrios modos de visualizao. Essa ferramenta identifica correntemente a maior parte dos Patterns estruturais e alguns tipos comportamentais descritos no livroDesign Patterns: Elements of Reusable Object-Oriented Software (Addison-

wesley, 1995), por Erich gamma, Richard Helm, John Vlissides, e Ralph Johnson ( The Gang of Four, ou "GoF"). A arquitetura global subsistemas principais: da DP++ consistem em trs

No primeiro passo, a ferramenta faz uma compilao parcial da fonte do projeto em C++, gerando um arquivo browser de banco de dados da fonte do projeto (*.bsc). Para a gerao desse arquivo a ferramenta utiliza o Microsoft Visual C++ 5.0. Alternativamente, o usurio pode especificar seu prprio arquivo fonte browser para o DP++ analisar diretamente. As informaes sobre a estrutura e funcionalidade das classes do projeto so subseqentemente pesquisadas no arquivo browser de dados e armazenadas em vrias estruturas de dados internas para acesso e manipulao mais eficientes. Os algoritmos de deteco de Patterns trabalham em cima dessas estruturas internas de dados. Aps esses passos, os componentes de display da ferramenta permite o usurio ver a estrutura do programa, os Patterns detectados e os agrupamentos de classes relacionadas. Como a prxima figura mostra, na ferramenta temos trs componentes de display disponveis: Um componente a janela "Text-View" que mostra as informaes sobre os Patterns e o contedo das classes. O segundo componente a janela "Tree view" que mostra a hierarquia de classe usando o controle de rvore. O componente de display mais importante a janela "Graph View" que mostra os Patterns identificados, os agrupamentos, relacionamentos e a colaborao das classes. Se um segundo projeto aberto para ser analisado, ele ter suas prprias janelas "Text View" e "Tree View". A

janela "Graph View" compartilhada por todos os projetos abertos. Ferramentas automatizadas como o DP++ podem sucintamente identificar, capturar, e representar a arquitetura interna, as solues Patterns, e as interaes estticas entre classes a partir do cdigo do projeto. A habilidade de visualizar a arquitetura do sistema como uma coleo de Patterns se interagindo e relacionamentos ao invs de uma coleo nebulosa de classes e implementaes de mtodos, isto , visualizar o sistema em nveis mais altos de abstrao, ajuda no processo de compreenso de sistemas de software orientados para objetos. A tentativa de identificar os Design Patterns na DP++ se baseia em pegar um mnimo de estrutura necessrio para se identificar uma soluo de Pattern. Contudo, uma tentativa baseada somente em estruturas de Patterns no completa porque essas estruturas no so suficientemente nicas. Vrios Patterns tendem a usar estruturas bsicas parecidas. Assim, para reduzir identificaes errneas ou no identificar a presena de um Pattern, a tcnica implementada pela ferramenta DP++ est sendo extendida para usar heursticas de projeto e dados empricos para tentar detectar a presena de Patterns. Essas heursticas e dados empricos esto sendo adaptados de mtricas de projeto e de implementao, que servem para avaliar a estrutura e caractersticas funcionais de classes e relacionamentos. Um repositrio e mecanismos para especificar thresholds para identificao de Patterns esto tambm sendo desenvolvidos para a DP++.

Consideraes Finais
Os design patterns ajudam a colocar ordem no caos, identificando o que constantemente se repete nas mais diversas configuraes de software. Eles representam experincia e conhecimento adquiridos, e que podem ser compartilhados entre os desenvolvedores de software. Escrever os design patterns custoso, visto que consiste em um processo iterativo, que muitas vezes envolve outros padres aplicados no projeto. Apesar disso, o esforo vale a pena. A disseminao desta prtica de fundamental importncia para que um dia todo desenvolvedor de software possa utilizar os padres. A criao de linguagens de padres que englobem diversos design patterns aplicados a um mesmo contexto e divididos em categorias, facilita muito a busca por um determinado padro. Alm disso, o uso da mesma minimiza a distoro que possa ser criada a partir de falso entendimento do sistema por parte dos desenvolvedores.

Webliografia
Doug Lea's "Patterns-Discussion FAQ" o http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html Doug Lea's paper, "Christopher Alexander: An Introduction for Object-Oriented Designers" o http://gee.cs.oswego.edu/dl/ca/ca/ca.html Jim Coplien's paper "Software Design Patterns: Common Questions and Answers" o ftp://st.cs.uiuc.edu/pub/patterns/papers/PatQandA .ps

 The "History of Patterns" on Ward Cunningham's WikiWiki Web o http://c2.com/cgi-bin/wiki?HistoryOfPatterns "Pattern Definitions" from the Patterns Home page o http://hillside.net/patterns/definition.htm "Design Patterns: Elements of Reusable Architectures", by Linda Rising o http://www.agcs.com/techpapers/patterns.htm Ward Cunningham's "Tips for Writing Pattern Languages" on the WikiWiki Web o http://c2.com/cgi/wiki?TipsForWritingPatternLangu ages "A Pattern Language for Pattern Writing" by Gerard Meszaros and Jim Doble o http://hillside.net/patterns/Writing/pattern_index.h tml The Patterns Home Page o http://hillside.net/patterns/patterns.html The Portland Pattern Repository o http://www.c2.com/ppr "Patterns and Software : Essential Concepts and Termilogy" o http://www.enteract.com/~bradapp/docs/patternsintro.html The OrganizationPatterns FrontPage o http://www.bell-labs.com/cgiuser/OrgPatterns/OrgPatterns Artigo AntiPatterns da revista Dr. Dobbs Journal de junho de 1998 "AntiPatterns: Refactoring Software, Architetures, and Project in Crisis" o http://www.antipatterns.com DPCpp Version 1.0 (DP++) o http://indus.cs.uah.edu Dr. Dobb's Web Site Home Page o http://www.ddj.com

 ModelMaker 4.01 o http://www.modelmaker.deamon.com Practical Use of Design Patterns in Delphi o http://www.barl.com/html/DesignPatterns/index.ht ml Introduction to Design Patterns in Delphi o http://www.obsof.com/pattern.html

Agradecimentos
Esta obra o resultado da experincia de vrias pessoas, que acreditam que a melhor forma do conhecimento o conhecimento compartilhado.