Estudo e Aplicação de Padrões

Transcrição

1 Estud e Aplicaçã de Padrões Jana M. F. Trindade, Lenard Garcia Fischer Institut de Infrmática Universidade Federal d Ri Grande d Sul (UFRGS) Caixa Pstal Prt Alegre RS Brasil 1. Intrduçã {jmftrindade,lgfischer}@inf.ufrgs.br Este trabalh faz uma apresentaçã ds padrões de prjet Singletn, Adapter e Observer [2] e ds padrões Data Access Object [7] e Mnitr [8]. Serã abrdads aspects estruturais e aplicabilidade de cada padrã, bem cm exempls de implementaçã. 2. O Padrã Singletn 2.1 Intençã O padrã de prjet Singletn pssui dis bjetivs: assegurar que uma classe será instanciada n máxim uma única vez durante a execuçã d códig, e prver um pnt de acess glbal à essa única instância. 2.2 Mtivaçã Existem diverss cntexts nde se deseja que s prgramadres tenham acess a exatamente um únic recurs d sistema. Alguns desses cass se devem à restrições físicas (pr exempl, acess à única impressra instalada n sistema). Em utrs cass, deseja-se essa restriçã para garantir desempenh da aplicaçã (pr exempl, evitar que uma classe que cupe uma grande quantidade de memória seja instanciada diversas vezes na aplicaçã). Em utrs cass, deseja-se garantir a única instância da classe para evitar prblemas de acess cncrrente (pr exempl, acess a sistema de arquivs). Nesses cass, uma sluçã que garanta que apenas uma instância de uma classe irá existir será sempre bem vinda. 2.3 Aplicabilidade O padrã de prjet Singletn pde ser aplicad a qualquer cas nde se deseja que uma classe pssua apenas uma única instância em execuçã. Incluem-se nesses cass as aplicações nde bjet singletn pssa ser utilizad pr diverss fluxs de execuçã paralels, u mesm váris prcesss diferentes. 2.4 Estrutura A seguir, é dispnibilizad diagrama UML que descreve padrã Singletn.

2 Singletn Singletn instance Singletn getsingletn() //Outras perações //da classe 2.5 Participantes A classe Singletn será a classe cuj cntrle de instância única será aplicad. Ela pssui cm respnsabilidades cntrle da criaçã da única instância, e prver pnt de acess a essa instância. Essa classe pderá pssuir também as respnsabilidades d dmíni a qual Singletn será aplicad. Os clientes sã tdas as utras classes que irã acessar a instância única através d métd getsingletn() da classe Singletn. 2.6 Clabrações Nesse padrã de prjet, irã crrer iterações entre a classe Singletn e s clientes. A classe Singletn pssui um métd estátic getsingletn() que frnece as clientes a única instância da classe. Desse md, garantims a existência de um pnt únic de acess a esse bjet. Para garantirms que bjet seja únic durante a execuçã, devems desabilitar acess a cnstrutr da classe pr utras classes. A única classe que deve pssuir acess a cnstrutr é a própria classe Singletn, e nenhuma utra. Iss pde ser feit trnand cnstrutr da classe privad. 2.7 Cnseqüências A primeira cnseqüência da descriçã acima é que s clientes nã precisam saber se já existe uma instância d bjet quand fr necessári. A chamar métd getsingletn(), própri métd pde ser capaz de verificar se existe a instância e, cas nã exista, criar ela. Outra cnseqüência é que métd getsingletn() pde criar a instancia apenas quand ele fr chamad, evitand a criaçã d bjet até que ele realmente seja necessári. Essa característica cstuma ser chamada de lazy initiatin. 2.8 Implementaçã A implementaçã d padrã Singletn é bastante simples. Para tal, devems primeir adicinar uma variável estática d mesm tip da classe na própria classe. Essa variável deverá ser privada, para evitar que utras classes pssam mdificá-la. A seguir, devems adicinar um métd públic e estátic getsingletn() à classe, que irá verificar se a instância fi criada. Se nã fi criada ainda, esse métd irá criar ela. Pr fim, esse métd retrna a instância armazenada.

3 Para garantir que a instância seja única, e que nenhum cliente pssa criar uma nva instancia da classe Singletn, devems prteger cnstrutr da classe, para que apenas métd getsingletn() pssa criar uma nva instância. Qualquer classe cliente irá fazer uma chamada a métd estátic getsingletn() para bter a instância única da classe. N mment em que fr feita a primeira chamada a métd a instância será criada. Nas chamadas seguintes, a mesma instância será retrnada. Um prblema da descriçã acima crre em ambientes de execuçã cncrrente (aplicações cm várias threads). Se duas threads da aplicaçã alcançarem a mesm temp métd getsingletn() antes da criaçã da instância, pde acntecer de que duas instâncias d bjet sejam criadas. Para reslver esse prblema, deve-se clcar um blquei de acess cncrrente (lcks, pr exempl) n trech d códig que verifica se a instância existe e cria ela. Outr prblema existente na descriçã acima pde depender das características da linguagem de prgramaçã nde Singletn será utilizad. Tmand a linguagem Java cm exempl, existem dis meis de garantir que apenas uma instância será criada. O primeir é fazer cm que cnstrutr da classe seja privad. Mas iss implica que a classe Singletn nã pssa ser entendida, pis as classes filhas nã terã acess a métd cnstrutr da classe pai. Cas seja necessári ter extensões da classe Singletn, cnstrutr deverá ser prtegid (n sentid da palavra reservada prtected da linguagem). Nesse cas, as utras classes que estã n mesm pacte d Singletn também terã acess a cnstrutr, que ns briga a clcar Singletn (e suas extensões) em um pacte separad d prjet. A seguir, a fim de exemplificar, será apresentad uma situaçã nde é adequad us d Singletn para reslver um prblema, e códig utilizad para reslve-l. Nas aplicações interativas (pr exempl, s jgs), cnsum de memória pr recurss cm sns, imagens, texturas, mdels, cenáris, etc., é muit grande. Nesses cass, é fundamental que minimizar a alcaçã em memória desses recurss repetidas vezes. Ou seja, devems evitar que, pr exempl, uma textura d cenári seja carregada várias vezes, mesm que ela seja utilizada em váris lugares diferentes d jg. Uma sluçã muit adtada nesses cass é a criaçã de uma classe chamada ResurceManager. Essa classe tem pr bjetiv carregar esse tip de recurs quand ele fr necessári, e prver mesm recurs carregad cas ele seja utilizad utras vezes. Para garantir que cada recurs seja carregad uma única vez, devems garantir que ResurceManager seja criad uma única vez. Pr iss, é nrmal implementá-l usand Singletn. Uma implementaçã dessa frma é feita pela bibliteca Ogre, que é uma engine de renderizaçã gráfica pen-surce muit utilizada para desenvlviment de jgs, em utras diversas aplicações gráficas, e n trabalh de cnclusã de curs de um ds autres deste trabalh. Pr já ser cnhecida pel autr, e pr ser pen-surce, será apresentad a seguir parte d códig utilizad para implementar Singletn na classe ResurceGrupManger da bibliteca Ogre (pr simplificaçã, s métds relativ a

4 carregament de recurss serã abstraíds d códig). O códig é apresentad em linguagem C++. ResurceGrupManager.h #ifndef RESOURCE_GROUP_MANAGER_H #define RESOURCE_GROUP_MANAGER_H #include "Texture.h" // Outrs includes namespace Ogre { class ResurceGrupManager { public: static ResurceGrupManager* getsingletn(); // Métd que irá carregar a textura cm // nme infrmad e retrná-la. // Cas já tenha sid carregada, apenas // retrna a textura. Texture* gettexture(cnst std::string& filename); // Outrs métds para carregar diverss recurss }; private: }; static ResurceGrupManager* instance; ResurceGrupManager.cpp using namespace Ogre; ResurceGrupManager* ResurceGrupManager::instance = NULL; ResurceGrupManager* ResurceGrupManager::getSingletn() { if(resurcegrupmanager::instance==null) ResurceGrupManager::instance = new ResurceGrupManager(); return ResurceGrupManager::instance; } // Implementaçã ds utrs métds da classe ResurceGrupManager A seguir, será mstrad cm uma classe cliente pde acessar Singletn. N cas, será exibid um pequen trech de uma rtina que precisa bter a textura de uma prta para utilizar em um utr bjet.... Texture* drtexture = ResurceGrupManager::getSingletn() ->gettexture("textures/dr.jpg");...

5 3. O Padrã Adapter (bjet) 3.1 Intençã O padrã de prjet Adapter pssui cm bjetiv cnverter a interface de uma classe em utra interface esperada pr uma aplicaçã cliente. Adapter auxilia em situações em que classes nã pderiam se cmunicar devid a incmpatibilidade entre interfaces diferentes. 3.2 Também cnhecid cm Wrapper 3.3 Mtivaçã Tem cm mtivaçã as situações em que querems reusar implementações de classes já existentes (biblitecas, tlkits, etc.) que implementam as funcinalidades em que estams interessads, mas nã necessariamente prvêm a interface desejada. Para este fim, entã, pde-se usar padrã Adapter, implementand uma classe adaptadra que envlve as funcinalidades implementadas pela classe já existente, mas prvend a interface que desejams. 3.4 Aplicabilidade Pde ser aplicad as seguintes cass: Querems usar uma classe existente, e sua interface nã é a que esperams. Querems criar uma classe reusável que cpera cm classes que nã necessariamente terã a mesma interface. 3.5 Estrutura O diagrama UML abaix (Fnte Wikipedia, [1]) descreve a estrutura da versã bjet d padrã Adapter. Nessa versã, bjet adaptadr (Adaptr) cntém uma instância da classe que envlve, fazend chamadas as métds desse bjet (Adaptee).

6 3.6 Participantes Target Client Adaptee Adapter Define a interface específica a dmíni que Client usa. N diagrama acima, Client faz requisições diretas a bjet Adaptr, pis Adaptr está em cnfrmidade cm as interfaces Adapter e Target neste cas. Clabra cm bjets que estã em cnfrmidade cm a interface Target. É bjet que implementa as funcinalidades que precisam de adaptaçã. Adapta a interface de Adaptee a interface de Target. 3.7 Clabrações Nesse padrã de prjet, clientes fazem chamadas a métds de instâncias de Adapter. Adapter, pr sua vez, faz a chamada a métd crrespndente de Adaptee. 3.8 Cnseqüências O us da versã bjet de Adapter, em cntraste cm a versã classe, pssibilita us de um únic Adapter cm váris Adaptees, e permite adicinar funcinalidades a tds s Adaptees de uma só vez. N entant, bjet adaptadr adicina restrições na hra de substituir cmprtament de Adaptee. Para cnseguir iss cm a versã bjet de Adapter, deve-se escrever uma utra classe que herda de Adaptee, e fazer cm que Adapter chame s métds desta classe, a invés ds de Adaptee. Outra questã é quant um Adapter deve adaptar d cmprtament de Adaptee. Um Adapter pde apenas fazer pequenas transfrmações na interface, até cas extrem de implementar diversas utras funcinalidades extras nã existentes em Adaptee. Iss deve ser determinad pel nível de diferenças entre a interface de Target e a de Adaptee. 3.9 Implementaçã O primeir pass para implementar Adapter é definir quais funções deveram fazer parte da interface Target. A partir diss, define-se quais métds de Adaptee serã reusads, e quais as transfrmações necessárias para que fique mais parecid cm a interface de Target. Cm iss em mente, Adapter chama s métds reusáveis de Adaptee, e implementa as funcinalidades que estiverem faltand para Target. Um exempl de pseudcódig escrit em Pythn [1] é mstrad abaix: # Pythn cde sample class Target(bject): def specific_request(self): return 'Hell Adapter Pattern!'

7 class Adapter(bject): def init (self, adaptee): self.adaptee = adaptee def request(self): return self.adaptee.specific_request() client = Adapter(Target()) print client.request() 4. O Padrã Observer 4.1 Intençã O padrã de prjet Observer pssui cm bjetiv definir uma relaçã de dependência (um pra muits) entre bjets, tal que, assim que estad de um bjet se altera, tds s seus bjets dependentes sã autmaticamente ntificads dessa alteraçã e atualizam seus estads. 4.2 Também cnhecid cm Dependents, Publish-Subscribe 4.3 Mtivaçã Situações em que váris bjets dependem d estad de um únic bjet para alterarem seus estads. Um exempl é cas de aplicações cm interface gráfica, em que diversas janelas mstram diferentes apresentações de um mesm cnjunt de dads. Usand este padrã, estas janelas pdem atuar cm bservers d estad atual d cnjunt de dads, que pde ntificá-las cada vez que seu estad fr alterad, fazend cm que as mesmas de atualizem de acrd. Assim, nã se precisa saber a priri quantas janelas devem ser mdificadas cada vez que cnjunt de dads fr alterad, apenas as janelas interessadas se registram para serem infrmadas cada vez que esse event acntecer. 4.4 Aplicabilidade Pde ser aplicad ns seguintes cass: Quand uma mudança em um bjet requer mudança em utrs, e nã se sabe de antemã quants bjets precisam ser mdificads. Quand um bjet deve ser capaz de ntificar utrs bjets sem assumir quais serã esses bjets. 4.5 Estrutura O diagrama UML abaix (Fnte: [2]) descreve a estrutura d padrã Observer:

8 4.6 Participantes Subject Observer CncreteSubject Interface que deve ser implementada pr bjets CncreteSubject a fim de que pssam ntificar bjets da mudança de seu estad. Cnhece seus Observers, cuj númer nã pssui restrições e pde variar. Define uma interface de atualizaçã para bjets que gstariam de ser ntificads de mudanças em um determinad Subject. É bjet que implementa a interface Subject e que pssui infrmações cncretas de estad. Quand seu estad é alterad, CncreteSubject ntifica seus bservadres. CncreteObserver Pssui uma referência a um bjet CncreteSubject, e guarda infrmações de estad que devem ser cnsistentes cm estad atual dessa referência. Implementa a interface de atualizaçã Observer, para receber ntificações de mudança n estad de um Subject. 4.7 Clabrações Nesse padrã de prjet, instâncias de CncreteSubject ntificam seus bservadres cada vez que uma mudança n seu estad crrer. Objets CncreteObserver, após receberem uma ntificaçã, pdem fazer requisições a Subject para bter infrmações adicinais sbre seu estad atual. A seqüência de ntificações é sempre iniciada pr um

9 Subject, que se encarrega de avisar a tds s seus Observers de mudanças em seu estad. 4.8 Cnseqüências Algumas cnseqüências psitivas d us d padrã Observer incluem a diminuiçã de acplament entre Subject e Observer e suprte para cmunicaçã bradcast. Cm cnseqüência negativa, pde-se citar fat de que a menr mudança de estad em um Subject pde causar uma reaçã em cadeia em Observers e seus bjets dependentes. Para reslver este prblema, pde-se extender a interface de atualizaçã de Observer para que inframações sbre aspects de interesse pssam ser passadas a um bjet CncreteObserver. Assim, apenas mudanças que interessam a determinad tip de Observer pdem ser filtradas. 5. Mnitr 5.1 Mtivaçã O padrã Mnitr é prpst cm padrã de cncrrência, e ferece uma maneira de sincrnizar duas u mais tarefas que acessam um recurs cmpartilhad. Esse padrã geralmente é ferecid em nível de linguagem, inserind travas de maneira transparentes a prgramadr para que especifique seções críticas de seu códig que devem ser acessadas apenas pr uma tarefa (e.g., thread, bjet) de cada vez. Iss pssibilita a prgramadr nã precisar se precupar cm primitivas de cncrrência u pssíveis cndições de crrida entre mais de uma tarefa acessand mesm recurs. Um recurs prtegid pr um mnitr varia de implementaçã para implementaçã, pdend ser um métd, uma variável, u qualquer trech de códig. Quand uma tarefa tenta acessar um recurs prtegid pr um mnitr, a mesma entra em uma fila de espera. Se nenhuma utra tarefa estiver esperand para acessar recurs, é dad direit de acess à tarefa, fazend cm que a trava seja acinada e quaisquer utras tarefas subseqüentes tenham de esperar para bterem acess. Assim que esta tarefa terminar de executar a regiã prtegida pel mnitr, ela libera mnitr, destravand a regiã para acess de utras tarefas. 5.2 Implementaçã Um exempl de implementaçã de Mnitr é ferecid pela linguagem Java. Neste exempl, tarefas sã threads Java e recurss sã métds u variáveis de bjets. Mdels de cncrrência suprtads sã exclusã mútua (regiã crítica acessada apenas pr uma thread de cada vez) e cperaçã (threads cperam entre si para acessarem um recurs e realizarem um prpósit). Para prteger uma seçã crítica de códig, basta usar a palavra reservada synchrnized da linguagem, cm n exempls abaix ([6]).

10 public class SynchrnizedCunter { private int c = 0; public synchrnized vid increment() { c++; } public synchrnized vid decrement() { c--; } } public synchrnized int value() { return c; } Iss garante que apenas uma thread pderá acessar a variável u executar s métds increment, decrement e value de cada vez. Uma vez que a thread tenha entrad na seçã crítica, mnitr é blquead e nenhuma utra thread pde executar a seçã. 6. O Padrã Data Access Object - DAO 6.1 Intençã O padrã Data Access Object (muit cnhecid cm DAO), tem cm bjetiv a abstraçã da manipulaçã ds bjets de negóci de uma aplicaçã e seu md de armazenament. 6.2 Mtivaçã É incntável a quantidade de meis de armazenament diferentes que pdems utilizar em uma aplicaçã. Pdems pensar em bancs de dads relacinais, bancs de dads rientads à bjets, arquivs de text, XML, etc. Mesm em um mesm tip de mei de armazenament, as diferenças entre s diverss fabricantes as vezes sã muit grandes. Além diss, pdems citar que pdems armazenar s dads lcal u remtamente. Durante desenvlviment de uma aplicaçã, devems cnsiderar que ela pderá ser mdificada a lng d temp. Pr exempl, um cliente pde desejar que a sua aplicaçã suprte um sistema de banc de dads mais simples, para crtar custs de desenvlviment. E após algum temp, cm cresciment d seu negóci, desejar que a aplicaçã suprte agra um banc de dads mais rbust, cm mair cmplexidade, desempenh, rbustez, etc. Em um cas cm este nenhuma regra de negóci é mdificada, apenas mei de armazenament ds dads. Pr esse mtiv, é interessante que desenvlvedr manipule armazenament das infrmações da aplicaçã de frma abstrata, permitind uma mudança futura cm um mínim de impact n rest da aplicaçã.

11 6.3 Aplicabilidade Assim, padrã de prjet DAO pde ser aplicad nas aplicações que façam acess a qualquer tip de banc de dads (relacinal, rientad à bjets, arquivs de text plen, arquivs XML, servidres remts, etc.), e que pssa ter que acessar utrs tips quaisquer durante u após desenvlviment da aplicaçã. 6.4 Estrutura A seguir, é apresentad um diagrama de classes apresentand s diverss participantes d padrã de prjet DAO: BusinessObject usa DataAccessObject busca/mdifica cria/usa encapsula TransferObject DataSurce 6.5 Participantes O TransferObject é bjet que será lid, manipulad e armazenad n banc de dads da aplicaçã. Vist de utra frma, é uma entidade que encapsula s dads a serem manipulads pelas regras de negóci, e serã transferids d mei de armazenament para a aplicaçã, e da aplicaçã para mei de armazenament. O DataSurce representa mei de armazenament d TransferObject. É ele bjet que se deseja abstrair da aplicaçã. O DataAccessObject é um bjet que irá encapsular as ações de leitura, escrita, atualizaçã e busca ds TransferObject sbre DataSurce. Ele deve pssuir uma interface abstrata e implementar as perações diretamente sbre DataSurce. Pr fim, BusinessObject representa tdas as classes de negóci da aplicaçã que irã manipular TransferObject. Esse bjet irá bter TransferObject d DataSurce através d DataAccessObject, usand a sua interface abstrata. Assim, BusinessObject nã tem cnheciment de cm deve ser realizada a manipulaçã d DataSurce, permitind que qualquer mudança na interface d DataSurce seja vista apenas pel DataAccessObject.

12 6.6 Clabrações O DataAccessObject é pnt central que separa as classes de negóci da frma cm que s dads que elas manipulam sã armazenads. Esse bjet pssui métds simples para acessar s dads n mei de armazenament, e nã deve pssuir nenhum métd públic para acess diret a mei de armazenament. Quant mair fr nível de abstraçã da interface pública d DataAccessObject, melhr aplicad será padrã de prjet. O TransferObject nã tem nenhuma funçã ativa neste padrã de prjet. Ele é apenas manipulad pels utrs bjets d sistema, e pssui a funçã de manter s dads a serem manipulads. Em algum sistema esse bjet pderá sim ter regras de negócis implementadas, mas a discussã sbre assunt fge d escp deste trabalh. Aqui, irems cnsiderar que esse bjet apenas pssui métds para a leitura e escrita de seus atributs. O DataSurce é bjet que representa mei de armazenament em si. Pde ser implementad pela representaçã em memória de um arquiv, uma API para leitura e escrita de XML, u uma cnexã a um banc de dads. O imprtante aqui é que DataAccessObject seja capaz de ler e gravar bjets d tip TransferObject n DataSurce, através ds métds que ele frnece para tal. O BusinessObject representa as classes que precisam manipular s TransferObject para cumprir a sua regra de negóci. Cm bjetiv d padrã de prjet DAO é justamente separar as regras de negóci d mei de armazenament, BusinessObject nã pde, de frma alguma, ler u gravar bjets TransferObject n DataSurce. Ele deverá utilizar DataAccessObject para essa tarefa. 6.7 Cnseqüências A principal cnseqüência d us d padrã DAO é a abstraçã d mei de armazenament. Cm iss pdems ter, pr exempl, uma equipe fcada n desenvlviment das regras de negóci, e uma equipe fcada n armazenament de dads da aplicaçã. Indiretamente, códig das regras de negóci será mais limp e legível, pr nã pssuir detalhes dependentes d DataSurce. Pr exempl, em uma aplicaçã de flha de pagament, um desenvlvedr pde se precupar em fazer tds s cálculs necessáris para cumprir brigações fiscais, sem sequer saber se s dads serã armazenads em um banc de dads u em um servidr remt. Tds s detalhes para manipular mei de armazenament estarã encapsulads n DataAccessObject, inclusive cnsultas SQL u tags XML. Além diss, ele pde simplificar a migraçã de um mei de armazenament para utr. Para iss, basta manter a mesma interface nas duas implementações d DataAccessObject. É pr esse mtiv que esse bjet precisa ser mais abstrat pssível. Quant mais abstrat ele fr, menres sã as chances de ser necessári mdificar partes d códig fra d DataAccessObject durante prcess de migraçã Outra cnseqüência é a adiçã de uma nva camada na aplicaçã. Iss pde ser ruim, pis pde aumentar a cmplexidade d códig, já que muitas classes de negóci irã

13 pderã necessitar manipular essa camada. Mas também tem a vantagem de centralizar td acess as dads n mei de armazenament, facilitand a manutençã da aplicaçã. 7. Referências [1] - Adapter Design Pattern, Wikipedia, kipedia.rg/wiki/adapter_pattern [2] - Gamma, E., Helm, R., Jhnsn, R., and Vlissides, J Design Patterns: Elements f Reusable Object-Oriented Sftware. Addisn-Wesley Lngman Publishing C., Inc. [3] - Geary, D., Simply Singletn, Site JavaWrld.cm, [4] - Ogre 3D, [5] - Singletn Pattern, [6] - Synchrnized Methds, The Java Tutrials, [7] - Cre J2EE Patterns - Data Access Object, [8] - Duglas C. Schmidt, Mnitr Object - An Object Behavir Pattern fr Cncurrent Prgramming, SIGS, 2000.