apostila padrões de software

Padres de Projeto de Software 0 PADRO ESDEPROJETOSDESOFTWARE

Apostila

Jorge Juan Zavaleta Gavidia

Rio de Janeiro, fevereiro de 2013

PADRES DE PROJETOS DE SOFTWARE

Jorge Juan Zavaleta Gavidia [email protected]

[email protected]

Termo de Uso

Todo o contedo desta apostila propriedade de Jorge Zavaleta. A apostila pode ser utilizada livremente para estudo pessoal. Alm disso, este material didtico pode ser utilizado como material de apoio em cursos de ensino superior desde que seja citado explicitamente o proprietrio do material assim como o livro E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Padres de Projetos: Solues reutilizveis de software orientado a objetos. Porto Alegre - RS: Bookman, 2000.

proibida qualquer utilizao desse material que no se enquadre nas condies acima sem o prvio consentimento formal, por escrito do autor. O uso indevido est sujeito s medidas legais cabveis.

Jorge Zavaleta

INDCE

1. INTRODUO ........................................................................................................ 1

1.1 O PARADIGMA DE ORIENTAO A OBJETOS ............................................... 1 1.1.1 Classes ................................................................................................................. 2

1.1.2 Objetos ................................................................................................................. 3

1.1.3 Herana ................................................................................................................ 4

1.1.4 Polimorfismo........................................................................................................ 5

1.2 A UML A Linguagem de Modelagem Unificada (Unified Modeling Language) ... 6 1.2.1 Classes ................................................................................................................. 6

1.2.2 Objetos ................................................................................................................. 7

1.2.3 Estados ................................................................................................................. 8

1.2.4 Pacotes ................................................................................................................. 8

1.2.5 Relacionamentos .................................................................................................. 9

1.2.5.1 Associaes ..................................................................................................... 10

1.2.5.2 Generalizaes ................................................................................................ 13

1.2.5.3 Dependncias e Refinamentos ......................................................................... 15

1.2.6 Mecanismos Gerais ............................................................................................ 16

1.3 PADRES DE PROJETOS DE SOFTWARE ....................................................... 17 1.4 O QUE UM PADRO DE PROJETO? ............................................................. 18 1.5 COMO DESCREVER UM PADRO DE PROJETO ........................................... 19 1.6 PRINCIPAIS PADRES DE PROJETO ............................................................... 20 1.6.1 Finalidade dos 23 padres: ................................................................................. 20

1.6.2 Como selecionar um padro? .............................................................................. 23

2. PADRES GoF ...................................................................................................... 24

2.1 PADRES DE CRIAO .................................................................................... 24 2.1.1 Padro Abstract Factory ..................................................................................... 24

2.1.2 Padro Builder ................................................................................................... 29

2.1.3 Padro Factory Method ...................................................................................... 32

2.1.4 Padro Prototype ................................................................................................ 36

2.1.5 Padro Singleton ................................................................................................ 40

2.2 PADRES ESTRUTURAIS ................................................................................. 43 2.2.1 Padro Adapter ................................................................................................... 43

2.2.2 Padro Bridge..................................................................................................... 47

2.2.3 Padro Composite .............................................................................................. 51

2.2.4 Padro Decorator ................................................................................................ 56

2.2.5 Padro Faade .................................................................................................... 59

2.2.6 Padro Flyweight ............................................................................................... 62

2.2.7 Padro Proxy ...................................................................................................... 66

2.3 PADRES COMPORTAMENTAIS ..................................................................... 70 2.3.1 Padro Chain of Responsability .......................................................................... 70

2.3.2 Padro Command ............................................................................................... 74

2.3.3 Padro Interpreter ............................................................................................... 78

2.3.4 Padro Iterator .................................................................................................... 82

2.3.5 Padro Mediator ................................................................................................. 86

2.3.6 Padro Memento ................................................................................................ 90

2.3.7 Padro Observer ................................................................................................. 93

2.3.8 Padro State ....................................................................................................... 96

2.3.9 Padro Strategy .................................................................................................. 99

2.3.10 Padro Template Method ................................................................................ 103

2.3.11 Padro Visitor ................................................................................................ 105

3. PADRES GRASP ............................................................................................... 111

4. ARQUITETURA EM CAMADAS ....................................................................... 112

REFERNCIAS ....................................................................................................... 113

Padres de Projeto de Software 1

Jorge Zavaleta, 2013 [email protected]

1. INTRODUO

Nesta seo apresenta-se uma introduo a um dos mtodos de desenvolvimento de software baseado em padres (os detalhes e as melhores prticas aprendidas por projetistas e usurios ao longo dos anos) e se apresenta os conceitos bsicos que permeiam o uso das tcnicas de orientao a objetos na programao, sempre utilizando a linguagem Java como motivador e a linguagem de modelagem (UML) que o suporta.

1.1 O PARADIGMA DE ORIENTAO A OBJETOS

Uma das atividades mais interessantes em Informtica certamente a busca constante de melhorias nas linguagens e tcnicas para o desenvolvimento de software. Desta busca decorrem as transformaes e evolues das linguagens de programao, surgindo novas linguagens e novos paradigmas.

A Programao Orientada a Objetos (POO) utiliza os conceitos que aprendemos no jardim de infncia: objetos e atributos, todos e partes, classes e membros. difcil explicar por que demoramos tanto a aplicar estes conceitos anlise e especificao de sistemas de informaes - talvez porque estivssemos ocupados demais olhando o auge da anlise estruturada para imaginar que havia alternativas.

Na compreenso do mundo real, as pessoas empregam constantemente trs mtodos de organizao, sempre presentes em todos os seus pensamentos:

1. Diferenciao, baseado na experincia de cada um, de objetos particulares e seus atributos - quando distinguem uma rvore, e seu tamanho ou relaes espaciais, dos outros objetos;

2. Distino entre objetos como um todo e entre suas partes componentes, por exemplo, quando separam uma rvore dos seus galhos; e

3. Formao de, e distino entre, as diferentes classes de objetos - por exemplo, quando formam uma classe de todas as rvores, outra classe de todas as rochas e distinguem-nas.

Programao Orientada a Objetos a programao implementada pelo envio de mensagens a objetos. Cada objeto ir responder s mensagens conhecidas por este, e cada objeto poder enviar mensagens a outros, para que sejam atendidas, de maneira que ao final do programa, todas as mensagens enviadas foram respondidas, atingindo-se o objetivo do programa. Programao Orientada a Objetos, tcnicas e artefatos ditos orientados a objetos incluem linguagens, sistemas, interfaces, ambientes de desenvolvimento, bases de dados, etc.

O paradigma de orientao a objetos centrado no conceito de objeto. Tudo esta focado nele. Escrevo cdigo organizado em torno de objetos, no de funes (SHALLOWAY e TROTT, 2004). Objetos so instncias de classes, que determinam qual informao um objeto contm e como ele pode manipul-la.



Um dos grandes diferenciais da programao orientada a objetos em relao a outros paradigmas de programao que tambm permitem a definio de estruturas e operaes sobre as mesmas esto no conceito de herana, mecanismo atravs do qual as definies existentes podem ser facilmente estendidas. Juntamente com a herana deve ser enfatizada a importncia do polimorfismo, que permite selecionar funcionalidades que um programa ir utilizar de forma dinmica, durante sua execuo.

1.1.1 Classes

A definio de classes e seus inter-relacionamentos o principal resultado da etapa de projeto de software. Em geral, esse resultado expresso em termos de alguma linguagem de modelagem, tal como UML.

Uma classe um gabarito para a definio de objetos. Atravs da definio de uma classe, descreve-se que propriedades ou atributos que o objeto ter. Alm da especificao de atributos, a definio de uma classe descreve tambm qual o comportamento de objetos da classe, ou seja, que funcionalidades podem ser aplicadas a objetos da classe. Essas funcionalidades so descritas atravs de mtodos. Um mtodo nada mais que o equivalente a um procedimento ou funo, com a restrio que ele manipula apenas suas variveis locais e os atributos que foram definidos para a classe.

Uma vez que estejam definidas quais sero as classes que iro compor uma aplicao, assim como qual deve ser sua estrutura interna e comportamento, possvel criar essas classes em Java.

Na UML, a representao para uma classe no diagrama de classes tipicamente expressa na forma grfica, como mostrado na Figura a seguir.

Como se observa na figura, a especificao de uma classe composta por trs regies: o nome da classe, o conjunto de atributos da classe e o conjunto de mtodos da classe. O nome da classe um identificador para a classe, que permite referenci-la posteriormente, por exemplo, no momento da criao de um objeto.

O conjunto de atributos descreve as propriedades da classe. Cada atributo identificado por um nome e tem um tipo associado. Em uma linguagem de programao orientada a objetos pura, o tipo o nome de uma classe. Na prtica, a maior parte das linguagens de programao orientada a objetos oferecem um grupo de tipos primitivos, como inteiro, real e carter, que podem ser usados na descrio de atributos. O atributo



pode ainda ter um valor default opcional, que especifica um valor inicial para o atributo.

Os mtodos definem as funcionalidades da classe, ou seja, o que ser possvel fazer com objetos dessa classe. Cada mtodo especificado por uma assinatura, composta por um identificador para o mtodo (o nome do mtodo), o tipo para o valor de retorno e sua lista de argumentos, sendo cada argumento identificado por seu tipo e nome.

Atravs do mecanismo de sobrecarga (overloading), dois mtodos de uma classe podem ter o mesmo nome, desde que suas assinaturas sejam diferentes. Tal situao no gera conflito, pois o compilador capaz de detectar qual mtodo deve ser escolhido a partir da anlise dos tipos dos argumentos do mtodo. Nesse caso, diz-se que ocorre a ligao prematura (early binding) para o mtodo correto.

O modificador de visibilidade pode estar presente tanto para atributos como para mtodos. Em princpio, trs categorias de visibilidade podem ser definidas:

+: Pblico: denotado em UML pelo smbolo (+), nesse caso, o atributo ou mtodo de um objeto dessa classe pode ser acessado por qualquer outro objeto (visibilidade externa total);

-: Privativo: denotado em UML pelo smbolo (-), nesse caso, o atributo ou mtodo de um objeto dessa classe no pode ser acessado por nenhum outro objeto (nenhuma visibilidade externa);

#: Protegido: denotado em UML pelo smbolo (#), nesse caso, o atributo ou mtodo de um objeto dessa classe poder ser acessado apenas por objetos de classes que sejam derivadas dessa atravs do mecanismo de herana.

1.1.2 Objetos

Objetos so instncias de classes. atravs deles que (praticamente) todo o processamento ocorre em sistemas implementados com linguagens de programao orientadas a objetos. O uso racional de objetos, obedecendo aos princpios associados sua definio conforme estabelecido no paradigma de desenvolvimento orientado a objetos, chave para o desenvolvimento de sistemas complexos e eficientes.

Um objeto um elemento que representa, no domnio da soluo, alguma entidade (abstrata ou concreta) do domnio de interesse do problema sobre anlise. Objetos similares so agrupados em classes.

No paradigma de orientao a objetos, tudo pode ser potencialmente representado como um objeto. Sob o ponto de vista da programao orientada a objetos, um objeto no muito diferente de uma varivel normal. Por exemplo, quando se define uma varivel do tipo int em uma linguagem de programao como C ou Java, essa varivel tem:

Um espao em memria para registrar o seu estado (valor);



Um conjunto de operaes que podem ser aplicadas a ela, atravs dos operadores definidos na linguagem que podem ser aplicados a valores inteiros.

Da mesma forma, quando se cria um objeto, esse objeto adquire um espao em memria para armazenar seu estado (os valores de seu conjunto de atributos, definidos pela classe) e um conjunto de operaes que podem ser aplicadas ao objeto (o conjunto de mtodos definidos pela classe). Um programa orientado a objetos composto por um conjunto de objetos que interagem atravs de trocas de mensagens. Na prtica, essa troca de mensagem traduz-se na aplicao de mtodos a objetos.

As tcnicas de programao orientada a objetos recomendam que a estrutura de um objeto e a implementao de seus mtodos devem ser to privativos como possvel. Normalmente, os atributos de um objeto no devem ser visveis externamente. Da mesma forma, de um mtodo deve ser suficiente conhecer apenas sua especificao, sem necessidade de saber detalhes de como a funcionalidade que ele executa implementada.

Encapsulao o princpio de projeto pelo qual cada componente de um programa deve agregar toda a informao relevante para sua manipulao como uma unidade (uma cpsula). Aliado ao conceito de ocultamento de informao um poderoso mecanismo da programao orientada a objetos. Ocultamento da informao o princpio pelo qual cada componente deve manter oculta sob sua guarda uma deciso de projeto nica. Para a utilizao desse componente, apenas o mnimo necessrio para sua operao deve ser revelado (tornado pblico).

Na orientao a objetos, o uso da encapsulao e ocultamento da informao recomenda que a representao do estado de um objeto deve ser mantida oculta. Cada objeto deve ser manipulado exclusivamente atravs dos mtodos pblicos do objeto, dos quais apenas a assinatura deve ser revelada.

O conjunto de assinaturas dos mtodos pblicos da classe constitui sua interface operacional. Dessa forma, detalhes internos sobre a operao do objeto no so conhecidos, permitindo que o usurio do objeto trabalhe em um nvel mais alto de abstrao, sem preocupao com os detalhes internos da classe. Essa facilidade permite simplificar a construo de programas com funcionalidades complexas, tais como interfaces grficas ou aplicaes distribudas.

1.1.3 Herana

O conceito de encapsular estrutura e comportamento em um tipo no exclusivo da orientao a objetos; particularmente, a programao por tipos abstratos de dados segue esse mesmo conceito. O que torna a orientao a objetos nica o conceito de herana.

Herana um mecanismo que permite que caractersticas comuns a diversas classes sejam fatoradas em uma classe base, ou superclasse. A partir de uma classe base, outras classes podem ser especificadas. Cada classe derivada ou subclasse



apresenta as caractersticas (estrutura e mtodos) da classe base e acrescenta a elas o que for definido de particularidade para ela.

H vrias formas de relacionamentos em herana:

Extenso: a subclasse estende a superclasse, acrescentando novos membros (atributos e/ou mtodos). A superclasse permanece inalterada, motivo pelo qual este tipo de relacionamento normalmente referenciado como herana estrita.

Especificao: a superclasse especifica o que uma subclasse deve oferecer, mas no implementa nenhuma funcionalidade. Diz-se que apenas a interface (conjunto de especificao dos mtodos pblicos) da superclasse herdada pela subclasse.

Combinao de extenso e especificao: a subclasse herda a interface e uma implementao padro de (pelo menos alguns de) mtodos da superclasse. A subclasse pode ento redefinir mtodos para especializar o comportamento em relao ao que oferecido pela superclasse, ou ter que oferecer alguma implementao para mtodos que a superclasse tenha declarado, mas no implementado. Normalmente, este tipo de relacionamento denominado herana polimrfica.

A ltima forma , sem dvida, a que mais ocorre na programao orientada a objetos. Algumas modelagens introduzem uma forma de herana conhecida como contrao. Contrao uma variante de herana onde a subclasse elimina mtodos da superclasse com o objetivo de criar uma classe mais simples. A eliminao pode ocorrer pela redefinio de mtodos com corpo vazio. O problema com este mecanismo que ele viola o princpio da substituio, segundo o qual uma subclasse deve poder ser utilizada em todos os pontos onde a superclasse poderia ser utilizada. Se a contrao parece ser uma soluo adequada em uma hierarquia de classes, provavelmente a hierarquia deve ser reanalisada para deteco de inconsistncias. De modo geral, o mecanismo de contrao deve ser evitado.

1.1.4 Polimorfismo

Polimorfismo o princpio pelo qual duas ou mais classes derivadas de uma mesma superclasse podem invocar mtodos que tm a mesma identificao (assinatura), mas comportamentos distintos, especializados para cada classe derivada, usando para tanto uma referncia a um objeto do tipo da superclasse. Esse mecanismo fundamental na programao orientada a objetos, permitindo definir funcionalidades que operem genericamente com objetos, abstraindo-se de seus detalhes particulares quando esses no forem necessrios.

Para que o polimorfismo possa ser utilizado, necessrio que os mtodos que estejam sendo definidos nas classes derivadas tenham exatamente a mesma assinatura do mtodo definido na superclasse; nesse caso, est sendo utilizado o mecanismo de redefinio de mtodos (overriding). Esse mecanismo de redefinio muito diferente do mecanismo de sobrecarga de mtodos, onde as listas de argumentos so diferentes.



No caso do polimorfismo, o compilador no tem como decidir qual o mtodo que ser utilizado se o mtodo foi redefinido em outras classes, afinal, pelo princpio da substituio um objeto de uma classe derivada pode estar sendo referenciado como sendo um objeto da superclasse. Se esse for o caso, o mtodo que deve ser selecionado o da classe derivada e no o da superclasse.

Dessa forma, a deciso sobre qual dos mtodos mtodo que deve ser selecionado, de acordo com o tipo do objeto, pode ser tomada apenas em tempo de execuo, atravs do mecanismo de ligao tardia. O mecanismo de ligao tardia tambm conhecido pelos termos em ingls late binding, dynamic binding ou ainda runtime binding.

1.2 A UML A Linguagem de Modelagem Unificada (Unified Modeling Language)

A UML uma linguagem visual utilizada para modelar softwares baseados no paradigma de orientao a objeto. uma linguagem de modelagem de propsito geral que pode ser aplicada a todos os domnios de aplicao. Essa linguagem tornou-se, nos ltimos anos, a linguagem padro de modelagem adotada internacionalmente pela indstria de engenharia do software (GUEDES, 2011).

A UML uma linguagem visual (isto , uma notao de desenho com semntica) utilizada para criar modelos de programas, ou quais podem ser entendidos como uma representao diagramtica dos programas. Nela podemos ver os relacionamentos entre os objetos no cdigo (SHALLOWAY e TROTT, 2004).

A UML possui diferentes tipos de diagramas, alguns para anlise, outros para projetos e outros ainda para implementao. Cada diagrama, dependendo de seu propsito, mostra os relacionamentos entre diferentes conjuntos de entidades.

1.2.1 Classes

Uma classe a descrio de um tipo de objeto. Todos os objetos so instncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Objetos s podem ser instanciados de classes. Usam-se classes para classificar os objetos que identificamos no mundo real. Uma classe pode ser a descrio de um objeto em qualquer tipo de sistema.

Em UML as classes so representadas por um retngulo dividido em trs compartimentos: o compartimento de nome, que conter apenas o nome da classe modelada, o de atributos, que possuir a relao de atributos que a classe possui em sua



estrutura interna, e o compartimento de operaes, que sero os mtodos de manipulao dedados e de comunicao de uma classe com outras do sistema. A sintaxe usada em cada um destes compartimentos independente de qualquer linguagem de programao, embora possam ser usadas outras sintaxes.

Exemplo: classe turma

Atributos: sala, horrio; Operaes: obter local, adicionar estudante, obter horrio;

1.2.2 Objetos

Um objeto um elemento que podemos manipular e acompanhar seu comportamento, criar, destruir, etc. Um objeto existe no mundo real. Pode ser uma parte de qualquer tipo de sistema, por exemplo, uma mquina, uma organizao, ou negcio. Existem objetos que no encontramos no mundo real, mas que podem ser vistos de derivaes de estudos da estrutura e comportamento de outros objetos do mundo real.

Um objeto num sistema possui trs propriedades: estado, comportamento e identidade:

Estado: definido pelo conjunto de propriedades do objeto (os atributos) e de suas relaes com os outros objetos. algo que muda com o tempo, por exemplo, um objeto turma pode estar no estado aberto ou fechado. Inicia no estado aberto e fecha quando 10 alunos fazem inscrio.

Comportamento: como um objeto responde s solicitaes dos outros e tudo mais o que um objeto capaz de fazer. implementado por um conjunto de operaes. Ex. objeto turma pode ter operaes acrescentar aluno ou suprimir aluno.

Identidade: significa que cada objeto nico no sistema. Por exemplo, o objeto turma Tecno-OO manh diferente do objeto Tecno-OO tarde.



Em UML um objeto mostrado como uma classe s que seu nome (do objeto) sublinhado, e o nome do objeto pode ser mostrado opcionalmente precedido do nome da classe.

1.2.3 Estados

Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, e normalmente determinada pelos valores de seus atributos e ligaes com outros objetos.

Um objeto muda de estado quando acontece algo, o fato de acontecer alguma coisa como objeto chamado de evento. Atravs da anlise da mudana de estados dos tipos de objetos de um sistema, podemos prever todos os possveis comportamentos dos objetos de acordo com os eventos que o mesmo possa sofrer.

Um estado, em sua notao, pode conter trs compartimentos. O primeiro mostra o nome do estado. O segundo opcional e mostra a varivel do estado, onde os atributos do objeto em questo podem ser listados e atualizados. Os atributos so aqueles mostrados na representao da classe, e em algumas vezes, podem ser mostradas tambm as variveis temporrias, que so muito teis em diagramas de estado, j que atravs da observncia de seus valores podemos perceber a sua influncia na mudana de estados de um objeto.

O terceiro compartimento opcional e chamado de compartimento de atividade, onde eventos e aes podem ser listados. Trs eventos padres podem ser mostrados no compartimento de atividades de um estado: entrar, sair e fazer. O evento entrar pode ser usado para definir atividades no momento em que o objeto entra naquele estado.

O evento sair define atividades que o objeto executa antes de passar para o prximo estado e o evento fazer define as atividades do objeto enquanto se encontra naquele estado.

1.2.4 Pacotes

Pacote um mecanismo de agrupamento, onde todos os modelos de elementos podem ser agrupados. Em UML, um pacote definido como: Um mecanismo de propsito geral para organizar elementos semanticamente relacionados em grupos. Todos os modelos de elementos que so ligados ou referenciados por um pacote so chamados de Contedo do pacote.



Um pacote possui vrios modelos de elementos, e isto significa que estes no podem ser includos em outros pacotes.

Pacotes podem importar modelos de elementos de outros pacotes. Quando um modelo de elemento importado, refere-se apenas a o pacote que possui o elemento. Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes no possuam semnticas definidas para suas instncias. Os relacionamentos permitidos entre pacotes so de dependncia, refinamento e generalizao (herana).

O pacote tem uma grande similaridade com a agregao (relacionamento que ser tratado mais na frente). O fato de um pacote ser composto de modelos de elementos cria uma agregao de composio. Se este for destrudo, todo o seu contedo tambm ser.

1.2.5 Relacionamentos

Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos:

Associao: uma conexo entre classes, e tambm significa que uma conexo entre objetos daquelas classes. Em UML, uma associao definida comum relacionamento que descreve uma srie de ligaes, onde a ligao definida como a semntica entre as duplas de objetos ligados.

Generalizao: um relacionamento de um elemento mais geral e outro mais especfico. O elemento mais especfico pode conter apenas informaes adicionais. Uma instncia (um objeto uma instncia de uma classe) do elemento mais especfico pode ser usada onde o elemento mais geral seja permitido.

Dependncia e Refinamentos: Dependncia um relacionamento entre elementos, um independente e outro dependente. Uma dependncia representada graficamente por uma seta aberta, com linha tracejada.



A seta que representa a relao de dependncia sai do item dependente e aponta para o item independente.

Uma modificao um elemento independente afetar diretamente elementos dependentes do anterior. Refinamento um relacionamento entre duas descries de uma mesma entidade, mas em nveis diferentes de abstrao.

1.2.5.1 Associaes

Uma associao representa que duas classes possuem uma ligao (link) entre elas, significando, por exemplo, que elas conhecem uma a outra, esto conectadas com, para cada X existe um Y e assim por diante. Classes e associaes so muito poderosas quando modeladas em sistemas complexos.

Associao Normal: O tipo mais comum de associao apenas uma conexo entre classes. representada por uma linha slida entre duas classes. A associao possui um nome (junto linha que representa a associao), normalmente um verbo, mas substantivos tambm so permitidos.

No exemplo grfico acima vemos um relacionamento por associao entre as classes Funcionrio e Departamento.

Pode-se tambm colocar uma seta no final da associao indicando que esta s pode ser usada para o lado onde a seta aponta. Mas associaes tambm podem possuir dois nomes, significando um nome para cada sentido da associao.

Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos esto relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vrios (0..* ou apenas*), um para vrios (1..*), dois (2), cinco para 11 (5..11) e assim por diante. tambm possvel expressar uma srie de nmeros como (1, 4, 6..12). Se no for descrito nenhuma multiplicidade, ento considerado o padro de um para um (1..1 ou apenas 1).

Associao Recursiva: possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa semanticamente a conexo entre dois objetos, mas os



objetos conectados so da mesma classe. Uma associao deste tipo chamada de associao recursiva.

Associao Qualificada: Associaes qualificadas so usadas com associaes de um para vrios (1..*) ou vrios para vrios (*). O qualificador (identificador da associao qualificada) especifica como um determinado objeto no final da associao n identificado, e pode ser visto como um tipo de chave para separar todos os objetos na associao. O identificador desenhado como uma pequena caixa no final da associao junto classe de onde a navegao deve ser feita.

Associao Exclusiva: Em alguns modelos nem todas as combinaes so vlidas, e isto pode causar problemas que devem ser tratados. Uma associao exclusiva uma restrio em duas ou mais associaes. Ela especifica que objetos de uma classe podem participar de no mximo uma das associaes em um dado momento. Uma associao exclusiva representada por uma linha tracejada entre as associaes que so partes da associao exclusiva, com a especificao {ou} sobre a linha tracejada.

No diagrama acima um contrato no pode se referir a uma pessoa e a uma empresa ao mesmo tempo, significando que o relacionamento exclusivo a somente uma das duas classes.



Associao Ordenada: As associaes entre objetos podem ter uma ordem implcita. O padro para uma associao desordenada (ou sem nenhuma ordem especfica). Mas uma ordem pode ser especificada atravs da associao ordenada. Este tipo de associao pode ser muito til em casos como este: janelas de um sistema tm que ser ordenadas na tela (uma est no topo, uma est no fundo e assim por diante). A associao ordenada pode ser escrita apenas colocando {ordenada} junto linha de associao entre as duas classes.

Associao de Classe: Uma classe pode ser associada outra associao. Este tipo de associao no conectada a nenhuma das extremidades da associao j existente, mas na prpria linha da associao. Esta associao serve para se adicionar informaes extras a associao j existente.

A associao da classe Fila com a associao das classes Cliente e Processo pode ser estendida com operaes de adicionar processos na fila, para ler e remover da fila e de ler o seu tamanho. Se operaes ou atributos so adicionados associao, ela deve ser mostrada como uma classe.

Associao Ternria: Mais de duas classes podem ser associadas entre si, a associao ternria associa trs classes. Ela mostrada como um losango grande (diamante) e ainda suporta uma associao de classe ligada a ela, se traaria, ento, uma linha tracejada a partir do losango para a classe onde seria feita a associao ternria.

No exemplo acima a associao ternria especifica que um cliente poder possuir 1oumais contratos e cada contrato ser composto de1 ou vrias regras contratuais.



Agregao: A agregao um caso particular da associao. A agregao indica que uma das classes do relacionamento uma parte, ou est contida em outra classe. As palavras chaves usadas para identificar uma agregao so: consiste em, contm, parte de. A agregao tambm conhecida como relacionamento tem-um, ou seja, dizemos que um objeto gerado da classe todo tem um objeto gerado da classe parte.

Existem tipos especiais de agregao que so as agregaes compartilhadas e as compostas.

Agregao Compartilhada: dita compartilhada quando uma das classes uma parte, ou est contida na outra, mas esta parte pode estar contida nas outras vrias vezes e num mesmo momento.

No exemplo acima uma pessoa pode ser membro de um time ou vrios times em determinado momento.

Agregao de Composio: uma agregao onde uma classe que est contida na outra vive e constitui a outra. Se o objeto da classe que contm for destrudo, as classes da agregao de composio sero destrudas juntamente j que as mesmas fazem parte da outra.

1.2.5.2 Generalizaes

A generalizao um relacionamento hierrquico entre classes, isto , a generalizao um relacionamento entre um elemento geral e outro mais especfico. O elemento mais especfico possui todas as caractersticas do elemento geral e contm ainda mais particularidades. Um objeto mais especfico pode ser usado como uma



instncia do elemento mais geral. A generalizao, tambm chamada de herana, permite a criao de elementos especializados em outros.

A classe de maior nvel hierrquico conhecida como superclasse, enquanto a outra classe da relao conhecida como subclasse. Graficamente uma generalizao representada por uma linha contnua com uma seta em branco apontando sempre a superclasse.

Existem alguns tipos de generalizaes que variam em sua utilizao a partir da situao. So elas: generalizao normal e restrita. As generalizaes restritas se dividem em generalizao de sobreposio, disjuntiva, completa e incompleta.

Generalizao Normal: Na generalizao normal a classe mais especfica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operaes e todas as associaes so herdados.

public class ContaCorrente {} public class Poupana extends ContaCorrente {}

Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que um grfico onde as classes esto ligadas atravs de generalizaes.

A generalizao normal representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalizao.

Generalizao Restrita: Uma restrio aplicada a uma generalizao especifica informaes mais precisas sobre como a generalizao deve ser usada e estendida no futuro. As restries a seguir definem mais generalizaes restritas com mais de uma subclasse:

Generalizaes de Sobreposio e Disjuntiva: Generalizao de sobreposio significa que quando subclasses herdam de uma superclasse por sobreposio,



novas subclasses destas podem herdar de mais de uma subclasse. A generalizao disjuntiva exatamente o contrrio da sobreposio e a generalizao utilizada como padro.

Generalizaes Completas e Incompletas: Uma restrio simbolizando que

uma generalizao completa significa que todas as subclasses j foram especificadas, e no existe mais possibilidade de outra generalizao a partir daquele ponto. A generalizao incompleta exatamente o contrrio da completa e assumida como padro da linguagem.

1.2.5.3 Dependncias e Refinamentos

Alm das associaes e generalizaes, existem a inda dois tipos de relacionamentos em UML. O relacionamento de dependncia uma conexo semntica entre dois modelos de elementos, um independente e outro dependente. Uma mudana no elemento independente ir afetar o modelo dependente.

Como no caso anterior com generalizaes, os modelos de elementos podem ser uma classe, um pacote, um caso de uso e assim por diante. Quando uma classe recebe um objeto de outra classe como parmetro, uma classe acessa o objeto global da outra.

Nesse caso existe uma dependncia entre estas duas classes, apesar de no ser explcita. Uma relao de dependncia simbolizada por uma linha tracejada com uma seta no final de um dos lados do relacionamento.



E sobre essa linha o tipo de dependncia que existe entre as duas classes. As classes Amigas provenientes do C++ so um exemplo de um relacionamento de dependncia

Os refinamentos so um tipo de relacionamento entre duas descries de uma mesma coisa, mas em nveis de abstrao diferentes e podem ser usados para modelar diferentes implementaes de uma mesma coisa (uma implementao simples e outra mais complexa, mas tambm mais eficiente).

Os refinamentos so simbolizados por uma linha tracejada comum tringulo no final de um dos lados do relacionamento e so usados em modelos de coordenao. Em grandes projetos, todos os modelos que so feitos devem ser coordenados.

Coordenao de modelos pode ser usada para mostrar modelos em diferentes nveis de abstrao que se relacionam e mostram tambm como modelos em diferentes fases de desenvolvimento se relacionam.

1.2.6 Mecanismos Gerais

AUML utiliza alguns mecanismos em seus diagramas para tratar informaes adicionais.

Ornamentos: Ornamentos grficos so anexados aos modelos de elementos em diagramas e adicionam semnticas ao elemento. Um exemplo de um ornamento o da tcnica de separar um tipo de uma instncia. Quando um elemento representa um tipo, seu nome mostrado em negrito. Quando o mesmo elemento representa a instncia de um tipo, seu nome escrito sublinhado e pode significar tanto o nome da instncia quanto o nome do tipo.

Outros ornamentos so os de especificao de multiplicidade de relacionamentos, onde a multiplicidade um nmero ou um intervalo que indica quantas instncias de um tipo conectado pode estar envolvido na relao.

Notas: Nem tudo pode ser definido em uma linguagem de modelagem, sem importar o quanto extensa ela seja. Para permitir adicionar informaes a um modelo no poderia ser representado de outra forma, UML prov a capacidade de adicionar Notas.

Uma Nota pode ser colocada em qualquer lugar em um diagrama, e pode conter qualquer tipo de informao.



1.3 PADRES DE PROJETOS DE SOFTWARE

Um dos principais problemas do desenvolvimento de software orientado a objetos projetar software reutilizvel. Na maioria das vezes, e isso aconteceu muito na dcada passada, e ainda acontece hoje, que h uma tendncia, mesmo em projetos com linguagens orientadas a objetos, em comear uma soluo do zero ou usar as velhas tcnicas estruturadas utilizadas durante muito tempo, assim mais fcil.

No entanto, o que deve ser observado, que j existem tcnicas orientadas a objetos que solucionam problemas recorrentes de software, no necessrio comear do zero ou partir para tcnicas usadas em um passado distante.

Essas tcnicas so denominadas padres de projeto (Design Patterns), assim, ao longo do processo evolutivo do desenvolvimento orientado a objetos foram surgindo solues brilhantes para problemas recorrentes de software, essas solues foram documentadas e reutilizadas para cada propsito, proporcionando rapidez no desenvolvimento de software, reutilizao de modelo de classes e cdigo e padronizao das solues.

Tudo comeou na dcada de 1970 quando Christopher Alexander, um arquiteto austraco, lanou as ideias iniciais sobre o uso de padres para o setor das construes. Em 1987, surgiram os primeiros padres para a rea de Cincia da Computao, propostos por Kent Beck e Ward Cunningham, usando a linguagem Smalltalk.

O modelo MVC (Model-View-Controller) foi um dos pioneiros, usado para atender usurios Smaltalk-80, esse modelo previa o Modelo (a aplicao), a Viso (a tela) e o Controlador (reao da interface dos usurios s entradas de dados do mesmo). Nesse modelo, eram apresentados os fundamentos dos padres de projeto e como esses poderiam evoluir para outras situaes recorrentes de produo de software.

Na dcada de 1990 surgiram os padres GoF (Gang of Four gangue dos quatro), dos autores Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Foi lanado o livro: Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed. Estados Unidos: Addison-Wesley, 1995. Mais tarde surgem outros padres como o padro GRASP (General Responsibility Assignment Software Patterns), mas de um modo geral, os 23 padres de projetos GoF definidos pela gangue do quatro, so os mais utilizados no mercado e so esses padres o objetivo do estudo.



1.4 O QUE UM PADRO DE PROJETO?

O Design Patterns so padres de classes e de relacionamentos entre as mesmas que aparecem de forma frequente em projetos de software. Tais padres so categorizados para atender a solues especficas. Sua utilizao uma atividade que simplifica a reutilizao de software. Os padres aparecem em situaes especiais dentro de um sistema como descries de objetos e classes comunicantes que so customizadas um contexto particular. Este descreve uma soluo comprovada para um problema, so mais abstratos, menores e menos especficos que frameworks que por sua vez um conjunto de classes que pode ser utilizado para um tipo especfico de projeto de software (anlise de domnio, biblioteca de reuso).

Os padres so dispositivos que permitem que os programas compartilhem conhecimento sobre o seu desenho. Quando programamos, encontramos muitos problemas que ocorrem, ocorreram e iro ocorrer novamente. A questo que nos perguntamos agora como ns vamos solucionar este problema desta vez? Documentar um padro uma maneira de poder reusar e possivelmente compartilhar informao que aprendeu sobre a melhor maneira de se resolver um problema de desenho de software. O catlogo de padres do GoF (Gang Of Four), contm 23 padres e est, basicamente, dividido em trs sees: Criao (Creational), Estrutural (Structural), Comportamental (Behavioral).

Dentre as principais propriedades dos padres de projetos podemos citar:

1. Capturam o conhecimento e a experincia de especialistas em projeto de software.

2. Especificam abstraes que esto acima do nvel de classes ou objetos isolados ou de componentes.

3. Definem um vocabulrio comum para a discusso de problemas e solues de projeto.

4. Facilitam a documentao e manuteno da arquitetura do software. 5. Auxiliam o projeto de uma arquitetura com determinadas propriedades. 6. Auxiliam o projeto de arquiteturas mais complexas.

Dentre os principais benefcios para a utilizao dos padres de projeto esto:

1. Fornecem solues que j foram testadas e aprovadas. 2. Tornam o sistema mais fcil de entender e manter. 3. Facilitam o desenvolvimento de mdulos coesos. 4. A comunicao entre os participantes do projeto fica mais eficiente

Quando e como utilizar padres de projetos. A primeira coisa que devemos ter bom senso. Teste e implemente sua soluo e veja se ela funciona. A seguir verifique se ela pode ser otimizada, se for o caso utilize o padro de projeto que se ajuste ao seu caso para melhorar as deficincias verificadas no seu projeto. Naturalmente isto ser mais fcil se tiver uma viso global do seu projeto e seu funcionamento.



Um padro de projeto pode ser definido como:

uma tcnica usada para identificar, abstrair, documentar e padronizar os diversos aspectos recorrentes do projeto de software orientado a objetos, de modo a torn-los reutilizveis em outros projetos (FREEMAN e FREEMAN, 2007).

os padres de projeto fornecem um vocabulrio compartilhado com outros desenvolvedores. Quando voc tem um vocabulrio, pode se comunicar mais facilmente com outros desenvolvedores e inspirar aqueles que no conhecem os padres a comear a aprend-los. Isso tambm eleva o seu raciocnio sobre as arquiteturas, permitindo que voc pense no nvel do padro e no no nvel de cdigo (FREEMAN e FREEMAN, 2007).

Cada padro descreve um problema no nosso ambiente e o cerne da sua soluo, de tal forma que voc possa usar essa soluo mais de um milho de vezes, sem nunca faz-lo da mesma maneira (GAMMA, HELM, et al., 2000).

Em geral, um padro tem quatro elementos essenciais:

1. Nome do Padro: Uma referncia usada para descrever um problema recorrente de projeto, suas solues e consequncias em uma ou duas palavras.

2. Problema: Usado para descrever em que situao o padro deve ser usado. Explica o problema e o contexto.

3. Soluo: Usado para descrever os elementos que compem o padro: relacionamentos, responsabilidades e colaboraes.

4. Consequncias: Vantagens e desvantagens da aplicao do padro.

1.5 COMO DESCREVER UM PADRO DE PROJETO

Existem diversas formas de descrever um padro de projeto. No entanto, independente do formato, alguns componentes devem ser facilmente reconhecidos quando da leitura de um padro de projeto. 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.

Inteno e Objetivo. uma curta declarao que responde s seguintes questes: o que faz o padro de projeto? Quais os seus princpios e sua inteno? Que tpico ou problema particular de projeto ele trata?

Propsito. O que faz um padro de projeto? Qual o problema que se prope a atacar? Quais 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 padro de projeto pode ser aplicado? Como reconhecer estas situaes?

Estrutura. Um diagrama da UML que represente o padro.



Participantes. Descreve as classes e/ou objetos que participam no padro de projeto 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.

Consequncias. Quais os resultados obtidos com a aplicao do padro de projeto? O que foi resolvido, o que no foi resolvido e que padro de projeto pode ser aplicado 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 uma linguagem especfica.

Exemplos de cdigo. Exemplos de sistemas reais, onde o padro de projeto foi aplicado e que transformaes ocorreram dentro de cada contexto.

Padres relacionados. Qual padro de projeto tem relao com este padro de projeto? Quais so as diferenas importantes? Com que outros padres, este deve ser usado.

1.6 PRINCIPAIS PADRES DE PROJETO

1.6.1 Finalidade dos 23 padres:

1. Adapter. Converter a interface de uma classe em outra interface esperada pelos clientes.

2. Faade. Oferecer uma interface nica de nvel mais elevado para um conjunto de interfaces de um subsistema.

3. Composite. Permitir o tratamento de objetos individuais e composies desses objetos de maneira uniforme.

4. Bridge. Desacoplar uma abstrao de sua implementao para que os dois possam variar independentemente.

5. Singleton. Garantir que uma classe s tenha uma nica instncia, e prover um ponto de acesso global a ela.

6. Observer. Definir uma dependncia um-para-muitos entre objetos para que quando um objeto mudar de estado, os seus dependentes sejam notificados e atualizados automaticamente.

7. Mediator. Definir um objeto que encapsula a forma como um conjunto de objetos interage.

8. Proxy. Prover um substituto ou ponto atravs do qual um objeto possa controlar o acesso a outro.

9. Chain of Responsibility. Compor objetos em cascata para, atravs dela, delegar uma requisio at que um objeto a sirva.

10. Flyweight. Usar compartilhamento para suportar eficientemente grandes quantidades de objetos complexos.

11. Builder. Separar a construo de objeto complexo da representao para criar representaes diferentes com mesmo processo.



12. Factory Method. Definir uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar.

13. Abstract Factory. Prover interface para criar famlias de objetos relacionados ou dependentes sem especificar suas classes concretas.

14. Prototype. Especificar tipos a criar usando uma instncia como prottipo e criar novos objetos ao copiar este prottipo.

15. Memento. Externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente.

16. Template Method. Definir o esqueleto de um algoritmo dentro de uma operao, deixando alguns passos a serem preenchidos pelas subclasses.

17. State. Permitir a um objeto alterar o seu comportamento quanto o seu estado interno mudar.

18. Strategy. Definir uma famlia de algoritmos, encapsular cada um, e faz-los intercambiveis.

19. Command. Encapsular requisio como objeto, para clientes parametrizarem diferentes requisies, filas, e suportar operaes reversveis.

20. Interpreter. Dada uma linguagem, definir uma representao para sua gramtica junto com um interpretador.

21. Decorator. Anexar responsabilidades adicionais a um objeto dinamicamente. 22. Iterator. Prover uma maneira de acessar elementos de um objeto agregado

sequencialmente sem expor sua representao interna. 23. Visitor. Representar uma operao a ser realizada sobre os elementos de uma

estrutura de objetos.

Os 23 padres de projeto se dividem em categorias segundo (GAMMA, HELM, et al., 2000), e so elas: Criao de classes de objetos, alterao da Estrutura de um programa, e controle de seu Comportamento. A figura 1 mostra os padres GoF, divididos em suas respectivas categorias.

O primeiro critrio, chamado de finalidade, reflete o que um padro faz. Os padres podem ter finalidade de criao, estrutural ou comportamental. Os padres de criao se preocupam com o processo de criao de objetos. Os padres de criao se preocupam com o processo de criao de objetos. Os padres estruturais lidam com a composio de classes ou de objetos. Os padres comportamentais caracterizam as maneiras pelas quais classes ou objetos interagem e distribuem responsabilidades.

O segundo critrio, chamado de escopo, especifica se o padro se aplica principalmente a classes ou objetos. Os padres para classes lidam com os relacionamentos entre classes e suas subclasses. Esses relacionamentos so estabelecidos atravs do mecanismo de herana, assim eles so estticos fixados em tempo de compilao. Os padres para objetos lidam com relacionamentos entre objetos que podem ser mudados em tempos de execuo e so mais dinmicos. Quase todos utilizam a herana em certa medida.



Figura 1: Classificao dos 23 padres segundo GoF

O primeiro critrio, chamado de finalidade, reflete o que um padro faz. Os padres podem ter finalidade de criao, estrutural ou comportamental. Os padres de criao se preocupam com o processo de criao de objetos. Os padres de criao se preocupam com o processo de criao de objetos. Os padres estruturais lidam com a composio de classes ou de objetos. Os padres comportamentais caracterizam as maneiras pelas quais classes ou objetos interagem e distribuem responsabilidades.

O segundo critrio, chamado de escopo, especifica se o padro se aplica principalmente a classes ou objetos. Os padres para classes lidam com os relacionamentos entre classes e suas subclasses. Esses relacionamentos so estabelecidos atravs do mecanismo de herana, assim eles so estticos fixados em tempo de compilao. Os padres para objetos lidam com relacionamentos entre objetos que podem ser mudados em tempos de execuo e so mais dinmicos. Quase todos utilizam a herana em certa medida.

Os padres de criao voltados para classes deixam alguma parte da criao de objetos para subclasses, enquanto que os padres de criao voltados para objetos postergam esse processo para outro objeto. Os padres estruturais voltados para classes utilizam a herana para compor classes, enquanto que os padres estruturais voltados para objetos descrevem maneiras de montar objetos. Os padres comportamentais voltados para classes usam a herana para descrever algoritmos e fluxo de controle, enquanto que os voltados para objetos descrevem como um grupo de objetos coopera para executar uma tarefa que um nico objeto no pode executar sozinho (GAMMA, HELM, et al., 2000).

Para Metsker (METSKER, 2002) os 23 padres so classificados em cinco grupos como mostrado na figura 2, por inteno (problema a ser solucionado):

1. Oferecer uma interface,



2. Atribuir uma responsabilidade, 3. Realizar a construo de classes ou objetos 4. Controlar formas de operao 5. Implementar uma extenso para a aplicao

Figura 2: Classificao dos padres GoF segundo Metsker

1.6.2 Como selecionar um padro?

1. Considere como os padres solucionam os problemas de projeto. 2. Analise seu problema e compare com o objetivo de cada padro. 3. Veja como os padres envolvidos se relacionam entre si. 4. Estude padres de propsito ou inteno similar (veja formas de classificao). 5. Examine causas comuns que podem forar o redesign do seu sistema. 6. Considere o que deve variar no seu design.



2. PADRES GoF

2.1 PADRES DE CRIAO

Os padres de criao abstraem o processo de instanciao. Eles ajudam a tornar um sistema independente de como seus objetivos so criados, compostos e representados.

Um padro de criao de classe usa a herana para variar a classe que instanciada, enquanto que um padro de criao de objeto delegar a instanciao para outro objeto.

2.1.1 Padro Abstract Factory

Propsito:

Fornecer uma interface para criao de famlias de objetos relacionados ou dependentes sem especificar suas classes concretas.

Motivao

Considere uma aplicao com interface grfica que implementada para plataformas diferentes (Motif para UNIX e outros ambientes para Windows e MacOS).

As classes implementando os elementos grficos no podem ser definidas estaticamente no cdigo. Precisamos de uma implementao diferente para cada ambiente. At em um mesmo ambiente, gostaramos de dar a opo ao usurio de implementar diferentes aparncias (look-and-feels).

Podemos solucionar este problema definindo uma classe abstrata para cada elemento grfico e utilizando diferentes implementaes para cada aparncia ou para cada ambiente.

Ao invs de criarmos as classes concretas com o operador new, utilizamos uma Fbrica Abstrata para criar os objetos em tempo de execuo.

O cdigo cliente no sabe qual classe concreta utilizamos.



Aplicabilidade

Use o padro Abstract Factory quando:

1. O sistema precisa ser independente de como os produtos so criados, compostos e representados.

2. O sistema deve ser configurado com uma de mltiplas famlias de produtos. 3. Produtos de uma famlia devem ser sempre utilizados em conjunto e isto

precisa ser garantido. 4. Deseja-se disponibilizar uma biblioteca de classes de produtos, mas revelar

somente as suas interfaces, no suas implementaes.

Estrutura

Participantes

AbstractFactory: o declara uma interface para operaes que criam objetos de produto

abstratos. ConcreteFactory:

o implementa as operaes para criar objetos produto concretos. AbstractProduct:

o declara uma interface para um tipo de objeto produto. ConcreteProduct:

o define o objeto produto a ser criado pela fbrica concreta correspondente e implementa a interface AbstractProduct.

Client: o usa somente interfaces declaradas pelas classes AbstractFactory e

AbstractProduct.



Colaboraes

Normalmente uma nica instncia de fbrica concreta criada em runtime. Esta fbrica cria produtos com uma implementao em particular. Para criar outros produtos deve-se utilizar uma fbrica diferente.

As classes abstratas transferem a responsabilidade de criao dos objetos produto para as suas subclasses.

Consequncias

Isola as classes concretas: Ele controla as classes dos objetos que a aplicao cria. Clientes manipulam instncias somente atravs de suas interfaces abstratas. Nomes de classes esto isolados nas fbricas concretas, eles no aparecem no cdigo do cliente.

Torna fcil a troca de famlias de produtos: A classe da fbrica concreta sendo utilizada aparece somente uma vez na aplicao, facilitando modificaes. A famlia de produtos mudaria toda de uma vez.

Promove consistncia entre produtos: Garante que os objetos utilizados so todos de uma mesma famlia, representada pela fbrica concreta sendo utilizada.

Dificulta a insero de novos tipos de produtos: A interface da fbrica abstrata torna fixo o conjunto de produtos que podem ser criados. Suportar um novo produto exige a extenso da interface da fbrica abstrata e a modificao de todas as suas subclasses.

Implementao. A seguir algumas tcnicas teis para implementar o padro Abstract factory.

Fbricas como Singletons: Geralmente precisa-se de somente uma instncia da fbrica concreta por aplicao.

Criando os produtos: A fbrica abstrata somente define uma interface para criao de produtos, geralmente atravs de um Factory Method para cada produto. As fbricas concretas implementam esses Factory Methods para instanciar os objetos. A implementao simples, mas requer uma fbrica concreta para cada famlia de produtos, mesmo que elas sejam ligeiramente diferentes. Se esto previstas muitas famlias, a fbrica concreta pode ser implementada usando o padro Prototype. Teramos apenas uma fbrica concreta, inicializada com os prottipos dos produtos desejados. Outra variao utilizar meta-classes, se disponveis na linguagem.

Definindo fbricas extensveis: Na fbrica abstrata, os tipos de produtos fazem parte das assinaturas dos Factory Methods. Adicionar um novo produto requer mudar a interface da fbrica abstrata e de todas as classes dela dependentes. Uma soluo mais flexvel porm menos segura adicionar um parmetro ao Factory Methodindicando o tipo de produto a ser criado. A fbrica abstrata (e concreta) teria somente um Factory Method.



Entretanto, visto que os produtos devero ter a mesma classe-base, o cliente os enxergar de uma nica maneira, sem distinguir os tipos dos produtos.

Exemplo prtico 1. Neste exemplo, a classe abstrata WidgetFactory possui duas especializaes: MotifWidgetFactory para widgets Motif e QtWidgetFactory para widgets Qt. Essas especializaes so classes concretas capazes de produzir os elementos da interface grfica. O cliente do toolkit obtm os elementos grficos de que necessita atravs da classe (interface) WidgetFactory sem ter conhecimento das classes concretas. Da mesma maneira, o cliente somente interage com as interfaces que representam os elementos produzidos pela classe Abstract Factory (no exemplo, a classe Janela e a classe Botao).

Figura 2: Estrutura exemplo prtico 1.

Implementao:

public abstract class E2WidgetFactory { public static E2WidgetFactory obterFactory(){ if( E2Configuracao.obterInterfaceGraficaAtual() == E2Configuracao.E2MotifWidget ){ return new E2MotifWidgetFactory(); } else{ return new E2QtWidgetFactory(); } } public abstract E2Botao criarBotao(); }

E2WidgetFactory.java public class E2QtWidgetFactory extends E2WidgetFactory{ @Override public E2Botao criarBotao() { return new E2BotaoQt(); } }

E2QtWidgetFactory.java public class E2MotifWidgetFactory extends E2WidgetFactory{ @Override public E2Botao criarBotao() { return new E2BotaoMotif(); } }



E2MotifWidgetFactory.java public abstract class E2Botao { public abstract void desenhar(); }

E2Botao .java public class E2BotaoMotif extends E2Botao{ @Override public void desenhar() { System.out.println(">> Eu sou um botao Motif! > Eu sou um botao Qt!



Triangulos (Ponto, Ponto, Ponto)

2.1.2 Padro Builder

Propsito

Separar a construo de um objeto complexo de sua representao para que o mesmo processo de construo possa criar representaes diferentes (GAMMA, HELM, et al., 2000). Mover a lgica de construo de uma classe para um objeto externo, a fim de reduzir a complexidade da mesma e permitir a construo gradual de objetos-alvo a partir dessa classe (METSKER, 2002).

Motivao

Nem sempre fcil coletar os requisitos que movem a criao de uma classe. Mais trabalhoso , porm, instanciar objetos de uma classe que variem de acordo com os requisitos apresentados. Por exemplo, mudar o layout de uma tela, em tempo de execuo, quando o usurio seleciona uma opo condizente.

Mas, se fosse possvel separar da classe os seus mtodos representam o comportamento e a construo dessa classe numa estrutura de dados a parte, seria possvel tambm, utilizar essa estrutura para coletar as opes de um cliente e construir objetos diferentes, conhecendo apenas os parmetros necessrios para esta construo, provenientes dos atributos que compem a classe em questo.

Desta maneira se apresenta o padro Builder, um construtor de objetos, baseado nos mtodos de criao e comportamento de uma classe, que pode instanciar objetos diferentes, conhecendo apenas os atributos que compem a classe em questo.

Aplicabilidade

Builder permite que uma classe se preocupe com apenas uma parte da construo de um objeto. til em algoritmos de construo complexos.

Use-o quando o algoritmo para criar um objeto complexo precisar ser independente das partes que compem o objeto e da forma como o objeto construdo.

Builder tambm suporta substituio dos construtores, permitindo que a mesma interface seja usada para construir representaes diferentes dos mesmos dados.

Use quando o processo de construo precisar suportar representaes diferentes do objeto que est sendo construdo.



Estrutura

Figura 3: Estrutura do Builder Participantes

Builder o Especifica uma interface abstrata para criao de partes de um objeto-

produto. ConcreteBuilder

o Constri e monta partes do produto pela implementao da interface de Builder; define e mantm a representao que cria; fornece uma interface para recuperao do produto.

Director. o Constri um objeto usando a interface de Builder.

Product o Representa o objeto complexo em construo. ConcreteBuilder constri a

representao interna do produto e define o processo pelo qual ele montado; inclui classes que definem as partes constituintes, inclusive as interfaces para a montagem das partes no resultado final.

Consequncias

Vantagens segundo (METSKER, 2002):

Reduo da extenso e da complexidade de uma classe; Independncia entre a representao de um objeto e a sua construo; Criao de regras graduais de construo para um objeto; Gerao de construes diversificadas de um tipo de objeto, ou de

construes de objetos diversificados entre si, a partir de um construtor-base;

Desvantagem:

1. Por ser bastante flexvel, este padro s apresentar desvantagem se o seu construtor-base for mal planejado, o que poderia resultar em construes redundantes ou com baixo aproveitamento operacional.



Exemplo prtico 2

Figura 4: UML exemplo 2

Implementao:

/** "Product" */ class Pizza { private String dough = ""; private String sauce = ""; private String topping = ""; public void setDough(String dough) { this.dough = dough; } public void setSauce(String sauce) { this.sauce = sauce; } public void setTopping(String topping) { this.topping = topping; } } /** "Abstract Builder" */ abstract class PizzaBuilder { protected Pizza pizza; public Pizza getPizza() { return pizza; } public void createNewPizzaProduct() { pizza = new Pizza(); } public abstract void buildDough(); public abstract void buildSauce(); public abstract void buildTopping(); } /** "ConcreteBuilder" */ class HawaiianPizzaBuilder extends PizzaBuilder { public void buildDough() { pizza.setDough("cross"); } public void buildSauce() { pizza.setSauce("mild"); } public void buildTopping() { pizza.setTopping("ham+pineapple"); } } /** "ConcreteBuilder" */ class SpicyPizzaBuilder extends PizzaBuilder { public void buildDough() { pizza.setDough("pan baked"); } public void buildSauce() { pizza.setSauce("hot"); } public void buildTopping() { pizza.setTopping("pepperoni+salami"); } } /** "Director" */



class Waiter { private PizzaBuilder pizzaBuilder; public void setPizzaBuilder(PizzaBuilder pb) { pizzaBuilder = pb; } public Pizza getPizza() { return pizzaBuilder.getPizza(); } public void constructPizza() { pizzaBuilder.createNewPizzaProduct(); pizzaBuilder.buildDough(); pizzaBuilder.buildSauce(); pizzaBuilder.buildTopping(); } } /** A customer ordering a pizza. */ class BuilderExample { public static void main(String[] args) { Waiter waiter = new Waiter(); PizzaBuilder hawaiian_pizzabuilder = new HawaiianPizzaBuilder(); PizzaBuilder spicy_pizzabuilder = new SpicyPizzaBuilder(); waiter.setPizzaBuilder( hawaiian_pizzabuilder ); waiter.constructPizza(); Pizza pizza = waiter.getPizza(); System.out.println(" Pizza tipo "+pizza.getDough()); } }

Exerccios 2:

1. Adicionar outros tipos de pizzas ao cdigo anterior. 2. Uma aplicao precisa construir objetos Pessoa, e Empresa. Para isto, precisa ler

dados de um banco para cada produto. 1. Para construir uma Pessoa preciso obter nome e identidade. Apenas se os

dois forem lidos a pessoa pode ser criada. 2. Para construir uma empresa preciso ler o nome e identidade do responsvel

e depois construir a pessoa do responsvel. 3. Mostre como poderia ser implementada uma aplicao que realizasse as tarefas

acima. Simule os dados com Strings.

2.1.3 Padro Factory Method

Propsito

Definir uma interface ou classe abstrata para a criao de um objeto, permitindo decidir qual das implementaes ou subclasses devem ser instanciadas; deixa uma classe deferir instanciao para subclasses (GAMMA, HELM, et al., 2000). Retornar uma instncia dentre muitas possveis classes, dependendo dos dados providos a ele.

Motivao

til para se construir objetos individuais, para um propsito especfico, sem que a construo requeira conhecimento das classes especficas sendo instanciadas. Uma classe de abstrao criada, contendo um mtodo em que decide qual das opes de classe retornar. Ento, apenas este mtodo invocado, sem conhecer a classe que ser retornada por ele. Por isso, este padro chamado de Factory Method (traduzindo:



mtodo-fbrica): um mtodo responsvel pela fabricao de um objeto (GAMMA, HELM, et al., 2000).

Aplicabilidade

Sugestes para o uso desse padro (GAMMA, HELM, et al., 2000):

2. Quando uma classe no pode antecipar ou conhecer a classe dos objetos que deve criar;

3. Quando uma classe quer suas subclasses para especificar os objetos que cria; 4. Quando classes delegam responsabilidade alguma das vrias subclasses

ajudantes, e deseja-se localizar qual a subclasse ajudante acessada.

Estrutura

Figura 5: Estrutura do padro Factory Method

Participantes

Creator. Declara o factory method (mtodo de fabricao) que retorna o objeto da classe Product (produto). Este elemento tambm pode definir uma implementao bsica que retorna um objeto de uma classe ConcreteProduct (produto concreto) bsica;

ConcreteCreator. Sobrescreve o factory method e retorna um objeto da classe ConcreteProduct;

Product. Define uma interface para os objectos criados pelo factory method; ConcreteProduct. Uma implementao para a interface Product.

Consequncias

Vantagens:

Elimina a necessidade de acoplar classes especficas para aplicao em nvel de cdigo (GAMMA, HELM, et al., 2000) na programao, se lida apenas com a superclasse ou interface, para conhecer os mtodos e



atributos de uma forma genrica, o que permite manipular as subclasses ou implementaes de maneira particular.

D maior flexibilidade para as classes criar objetos numa classe que possui o mtodo-fbrica sempre mais flexvel que faz-lo em separado, assim o mtodo-fbrica funciona como uma conexo para que uma das subclasses possa prover uma verso estendida de um objeto.

Desvantagem:

Em alguns casos, pode ser criada uma relao superclasse-subclasse para a criao de classes que suportam o mtodo-fbrica, e de acordo com a classe a ser criada, uma das vrias subclasses podem sobrescrever o mtodo-fbrica, a fim de conectar hierarquias de classes paralelas e fornecer maior portabilidade (GAMMA, HELM, et al., 2000). Entretanto, esta uma soluo vivel se, e somente se, a especializao da classe do mtodo fbrica no for estritamente necessria (como no caso de um nmero elevado de implementaes diferentes para o mtodo-fbrica). Caso contrrio, a relao custo-planejamento-implementao de se especializar uma classe apenas para instanciar um objeto de uma subclasse de outra superclasse pode se revelar bastante improdutiva, podendo-se optar por uma alternativa mais simples como a criao classes para o mtodo-fbrica em separado

Exerccio prtico 3

Figura 6: UML do Exemplo 3

Implementao

/** * Abstrao de uma Aplicao capaz de manipular * documentos. */ abstract class Aplicacao {



private Documento doc; /** * Abstrao do Factory Method */ abstract Documento criaDocumento(); void novoDocumento() { this.doc = this.criaDocumento(); } void abrirDocumento() { this.doc.abrir(); } } /** * Abstrao de um Documento. */ abstract class Documento { void abrir() { System.out.println("Documento:Abrir documento!"); } void fechar() { System.out.println("Documento:Fechar documento!"); } void gravar() { System.out.println("Documento:Gravar documento!"); } } /** * Esta classe concreta contm a implementao * de uma aplicao capaz de manipular documentos * do tipo MeuDocumento. */ class MinhaAplicacao extends Aplicacao { /** * Uma implementao do Factory Method. Este mtodo * especializado na criao de documentos do tipo MeuDocumento */ Documento criaDocumento() { return new MeuDocumento(); } } /** * Esta classe concreta contm a implementao * de um tipo de documento especfico. */ class MeuDocumento extends Documento { private String word ="Word"; private String excel="Excel"; } /* testde Factory Method */ public class FactoyMethodTest { public static void main(String[] args){ MinhaAplicacao aplicacao = new MinhaAplicacao(); Documento docu = aplicacao.criaDocumento(); docu.abrir(); // MeuDocumento documento = new MeuDocumento(); System.out.println(" Documento: "+documento.getWord()); } }



Exerccios 3.

1. Implemente a aplicao mostrada na figura 7 abaixo usando Factory Method para criar os objetos.

2. Crie um objeto construtor para cada tipo de objeto (XXXFactory para criar figuras do tipo XXX)

3. Utilize a fachada Figura, onde os construtores so guardados, e um mtodo esttico que seleciona o construtor desejado com uma chave.

Figura 7: Exerccio a ser implementado

2.1.4 Padro Prototype

Propsito

Especificar os tipos de objetos a serem criados, usando uma instncia prototpica, criando novos objetos atravs da cpia desse prottipo. Substituir a gerao de instncias no-inicializadas de uma classe, fornecendo novos objetos a partir de uma classe-exemplo.

Motivao

A criao de classes se faz mais simples quando possvel partir de um exemplo, para ento criar as especializaes condizentes com as necessidades do domnio da aplicao. Uma alternativa criar classes especializadas que herdem, ou seja, que sejam subclasses, de uma classe com atributos e mtodos mais genricos (ou at mesmo uma classe abstrata) com parmetros de visibilidade acessveis, alterando-os apenas quando for preciso na criao da classe especializada.

Entretanto, essa alternativa apresenta um problema de ordem prtica: a gerao excessiva de classes especializadas (ou subclasses), para cada necessidade especfica, pode inchar o sistema, fazendo com que essas classes sempre sejam carregadas, mesmo que o seu uso seja reduzido. Ainda, tratando-se de visibilidade, para a criao de subclasses, estas devem conhecer a superclasse que lhes fornecer as caractersticas comuns a elas, para que, ento, sejam diferenciadas, segundo as necessidades de cada objeto.

Para sistemas remotos, nem sempre isso possvel: na maioria das situaes, um servidor de classes fica isolado dos clientes, e estes no podem conhecer a estrutura da



superclasse; apenas podem saber dos parmetros a serem informados em chamadas de mtodos que participam da criao de produtos (que no caso, seriam as subclasses).

Nesse contexto, Prototype se dispe a simplificar a criao de novas classes a partir de uma classe-exemplo, copiando-a fielmente, para que, nessa cpia, sejam feitas as especializaes intrnsecas a cada dependncia da aplicao. Alm de reduzir sensivelmente o nmero de classes o uso desse padro isola o usurio da estrutura do objeto, ou a classe-exemplo de seus produtos o que ainda facilita a criao de novas classes-exemplo, quando for estritamente necessrio.

Aplicabilidade

O padro Prototype pode ser utilizado em sistemas que precisam ser independentes da forma como os seus componentes so criados, compostos e representados. O padro Prototype pode ser til em sistemas com as seguintes caractersticas:

Sistemas que utilizam classes definidas em tempo de execuo; Sistemas que utilizam o padro Abstract Factory para criao de objetos. Neste

caso, a hierarquia de classes pode se tornar muito complexa e o padro Prototype pode ser uma alternativa mais simples, por realizar a mesma tarefa com um nmero reduzido de classes;

Sistemas que possuem componentes cujo estado inicial possui poucas variaes e onde conveniente disponibilizar um conjunto pr-estabelecido de prottipos que do origem aos objetos que compem o sistema.

Quando as classes para instanciao so especificadas em tempo de execuo ou carregadas dinamicamente;

Para evitar a construo de uma hierarquia de classes-exemplo estritamente especializada ou demasiadamente ligada a um tipo de produto;

Quando as instncias de uma classe podem ter apenas uma ou poucas maneiras de manifestar seu estado.

Estrutura

Figura 8: Estrutura UML do padro Prototype



Participantes

Prototype. Uma classe que declara uma interface para objetos capazes de clonar a si mesmo;

PrototypeConcreto. Implementao uma operao para clonar a si prprio. Cliente. Cria um novo objeto atravs de um prottipo que capaz de clonar a si

mesmo.

Consequncias

Vantagens:

Isolamento entre os produtos (subclasses ou implementaes) e suas classes-exemplo; esta vantagem se d por dois fatores:

o Facilita a criao de novas classes-exemplo quando for devidamente necessrio menos acopladas, o que apropriado para classes que diferem apenas em seus atributos, mas no em seus comportamentos;

o Fornece de forma transparente e independente acesso ao sistema, apenas pelo conhecimento dos parmetros necessrios para a criao das cpias, a partir das classes exemplo.

Reduo do nmero de subclasses: as cpias podem suprir as especializaes sejam elas por herana ou por implementao de interfaces pois uma vez criadas com um formato padro, podem ser modificadas dentro de cada contexto e necessidade inerentes aplicao.

Configurao para o carregamento dinmico de novas classes: com este padro, possvel configurar a instanciao de classes que originalmente no estavam ligadas ao programa, pois ao invs de invocar um construtor esttico, d suporte criao de instncias em tempo de execuo, assim que sua respectiva classe carregada.

Desvantagem:

A nica desvantagem encontrada foi a da utilizao do mtodo Clone: o Este mtodo cria uma cpia exata de um objeto que lhe for passado como

parmetro. Uma cpia exata carrega consigo uma espcie de fotografia do objeto: no apenas seu comportamento clonado, mas tambm seu estado, ou seja, um novo objeto com os mesmos campos do objeto original;

o Entretanto, quando se quer copiar um objeto, quase sempre se deseja um novo objeto e no um objeto novo, o que significa uma cpia no instanciada daquele objeto, ou com os campos ajustados para valores iniciais, que sejam default para toda a aplicao.

Assim, o programador deve ter em mente esta diferena ao implementar este padro, pois objetos clonados podem apresentar problemas de incluso de



classes no existentes e/ou referencias circulares (dependncias de parmetros ou resultados que sejam internos aos objetos e que no sejam levados em considerao na clonagem).

Exerccio pratico 4

Figura 8: Exemplo do padro Prototype

Implementao

/** * Prototype class */ abstract class Prototype implements Cloneable { @Override public Prototype clone() throws CloneNotSupportedException { return (Prototype)super.clone(); } public abstract void setX(int x); public abstract void printX(); public abstract int getX(); } /** * Implementation of prototype class */ class PrototypeImpl extends Prototype { int x; public PrototypeImpl(int x) { this.x = x; } public void setX(int x) { this.x = x; } public void printX() { System.out.println("Valor :" + x); } public int getX() { return x; } } /**



* Client code */ public class PrototypeTest { public static void main(String args[]) throws CloneNotSupportedException { Prototype prototype = new PrototypeImpl(1000); for (int i = 1; i < 10; i++) { Prototype tempotype = prototype.clone(); // Usage of values in prototype to derive a new value.

apostila padrões de software

Documents