Java XML Ajax Padroes Livro Wikipedia

Java e Padrões de Projeto
Conhecimentos Básicos
PDF gerado usando o pacote de ferramentas em código livre mwlib. Veja http://code.pediapress.com/ para mais informação.
PDF generated at: Fri, 20 Aug 2010 20:05:17 UTC
Conteúdo
Páginas
Introdução 1
Java (linguagem de programação) 1
Padrão de projeto de software 11
Padrões de Criação 15
Abstract Factory 15
Builder 20
Factory Method 24
Prototype 30
Singleton 33
Padrões Estruturais 38
Adapter 38
Bridge (padrão de projeto de software) 39
Composite 40
Decorator 41
Façade 42
Flyweight 43
Proxy (padrões de projeto) 43
Padrões Comportamentais 46
Chain of Responsibility 46
Command 47
Interpreter 48
Iterator 48
Mediator 48
Memento (informática) 52
Observer 52
State 53
Strategy 53
Template Method 54
Visitor 57
Ajax 58
AJAX (programação) 58
JavaScript 63
JavaScript 63
XML 71
XML 71
Referências
Fontes e Editores da Página 76
Fontes, licenças e editores da imagem 77
Licenças das páginas

Licença 78
1
Introdução
Java (linguagem de programação)

Java
Paradigma orientação a objeto
Surgido em 1995
Criado por Sun Microsystems
Estilo de tipagem: estática, forte
Compiladores GCJ, Javac
Influenciada por Objective-C, C++, Smalltalk
Influenciou C#, Fantom, J#, Jython
Java é uma linguagem de programação orientada a objeto desenvolvida na década de 90 por uma equipe de
programadores chefiada por James Gosling, na empresa Sun Microsystems. Diferentemente das linguagens
convencionais, que são compiladas para código nativo, a linguagem Java é compilada para um "bytecode" que é
executado por uma máquina virtual. A linguagem de programação Java é a linguagem convencional da Plataforma
Java, mas não sua única linguagem.
Histórico
Em 1991, na Sun Microsystems, foi iniciado o Green Project, o berço do Java, uma linguagem de programação
orientada a objetos. Os mentores do projeto eram Patrick Naughton, Mike Sheridan, e James Gosling. O objetivo do
projeto não era a criação de uma nova linguagem de programação, mas antecipar e planejar a “próxima onda” do
mundo digital. Eles acreditavam que, em algum tempo, haveria uma convergência dos computadores com os
equipamentos e eletrodomésticos comumente usados pelas pessoas no seu dia-a-dia.
Para provar a viabilidade desta idéia, 13 pessoas trabalharam arduamente durante 18 meses. No verão de 1992 eles
emergiram de um escritório de Sand Hill Road no Menlo Park com uma demonstração funcional da idéia inicial. O
protótipo se chamava *7 (leia-se “StarSeven”), um controle remoto com uma interface gráfica touchscreen. Para o
*7, foi criado um mascote, hoje amplamente conhecido no mundo Java, o Duke. O trabalho do Duke no *7 era ser
um guia virtual ajudando e ensinando o usuário a utilizar o equipamento. O *7 tinha a habilidade de controlar
diversos dispositivos e aplicações. James Gosling especificou uma nova linguagem de programação para o *7.
Gosling decidiu batizá-la de “Oak”, que quer dizer carvalho, uma árvore que ele podia observar quando olhava pela
sua janela.
O próximo passo era encontrar um mercado para o *7. A equipe achava que uma boa idéia seria controlar televisões
e vídeo por demanda com o equipamento. Eles construíram um demo chamado MovieWood, mas infelizmente era
muito cedo para que o vídeo por demanda bem como as empresas de TV a cabo pudessem viabilizar o negócio. A
idéia que o *7 tentava vender, hoje já é realidade em programas interativos e também na televisão digital. Permitir ao
telespectador interagir com a emissora e com a programação em uma grande rede de cabos, era algo muito visionário
e estava muito longe do que as empresas de TV a cabo tinham capacidade de entender e comprar. A idéia certa, na
época errada.
Entretanto, o estouro da Internet aconteceu e rapidamente uma grande rede interativa estava se estabelecendo. Era
este tipo de rede interativa que a equipe do *7 estava tentando vender para as empresas de TV a cabo. E, da noite
para o dia, não era mais necessário construir a infra-estrutura para a rede, ela simplesmente estava lá. Gosling foi
incumbido de adaptar o Oak para a Internet e em janeiro 1995 foi lançada uma nova versão do Oak que foi
rebatizada para Java. A tecnologia Java tinha sido projetada para se mover por meio das redes de dispositivos
heterogêneos, redes como a Internet. Agora aplicações poderiam ser executadas dentro dos browsers nos Applets
Java e tudo seria disponibilizado pela Internet instantaneamente. Foi o estático HTML dos browsers que promoveu a
rápida disseminação da dinâmica tecnologia Java. A velocidade dos acontecimentos seguintes foi assustadora, o
número de usuários cresceu rapidamente, grandes fornecedores de tecnologia, como a IBM anunciaram suporte para
a tecnologia Java.
Desde seu lançamento, em maio de 1995, a plataforma Java foi adotada mais rapidamente do que qualquer outra
linguagem de programação na história da computação. Em 2004 Java atingiu a marca de 3 milhões de
desenvolvedores em todo mundo[1] . Java continuou crescendo e hoje é uma referência no mercado de
desenvolvimento de software. Java tornou-se popular pelo seu uso na Internet e hoje possui seu ambiente de
execução presente em web browsers, mainframes, SOs, celulares, palmtops, cartões inteligentes etc.
Padronização
Em 1997 a Sun Microsystems tentou submeter a linguagem a padronização pelos órgãos ISO/IEC e ECMA, mas
acabou desistindo. [2] [3] [4] Java ainda é um standard de fato, que é controlada através da JCP Java Community
Process.[5] Em 13 de Novembro de 2006, a Sun lançou a maior parte do Java como Software Livre sob os termos da
GNU General Public License (GPL). Em 8 de Maio de 2007 a Sun finalizou o processo, tornando praticamente todo
o código Java como software de código aberto, menos uma pequena porção da qual a Sun não possui copyright.[6]
Principais Características da Linguagem Java

A linguagem Java foi projectada tendo em vista os seguintes objectivos:
• Orientação a objecto - Baseado no modelo de Simula67;
• Portabilidade - Independência de plataforma - "escreva uma vez, execute em qualquer lugar" ("write once, run
anywhere");
• Recursos de Rede - Possui extensa biblioteca de rotinas que facilitam a cooperação com protocolos TCP/IP, como
HTTP e FTP;
• Segurança - Pode executar programas via rede com restrições de execução;
Além disso, podem-se destacar outras vantagens apresentadas pela linguagem:
• Sintaxe similar a Linguagem C/C++.
• Facilidades de Internacionalização - Suporta nativamente caracteres Unicode;
• Simplicidade na especificação, tanto da linguagem como do "ambiente" de execução (JVM);
• É distribuída com um vasto conjunto de bibliotecas (ou APIs);
• Possui facilidades para criação de programas distribuídos e multitarefa (múltiplas linhas de execução num mesmo
programa);
• Desalocação de memória automática por processo de coletor de lixo (garbage collector);
• Carga Dinâmica de Código - Programas em Java são formados por uma colecção de classes armazenadas
independentemente e que podem ser carregadas no momento de utilização.
Exemplos de código
Método main
O método main é onde o programa inicia. Pode estar presente em qualquer classe. Os parâmetros de linha de
comando são enviados para a array args[], do tipo String.
public class OlaMundo {
/**
* Método que executa o programa
* public = É visto em qualquer lugar da aplicação
* static = é iniciado automaticamente pela JVM, sem precisar de uma
instância
* void = Método sem retorno (retorno vazio)
* main = Nome do método, que é obrigatorio ser este. Recebe como
parâmetro um array de String.
* String[] args = Array de argumentos que podem ser repassados na
chamada do programa.
*/
public static void main(String[] args) {

System.out.println("Olá, Mundo!"); //Imprime na tela a frase
}
}
Criação de classes
Exemplo:
public abstract class Animal {

public abstract void fazerBarulho();
}
----
public class Cachorro extends Animal {

public void fazerBarulho() {
System.out.println("AuAu!");
}
}
----
public class Gato extends Animal {

System.out.println("Miau!");
}
}
O exemplo acima cria a classe Animal e duas classes derivadas de Animal.

Java não suporta herança múltipla, e todas as classes em Java derivam de Object(Classe).
A única possibilidade de se ver herança múltipla em java é no uso de interfaces, pois uma so interfaces pode herdar
várias outras interfaces.
Interfaces
Uma interface modela um comportamento esperado. Pode-se entendê-la como uma classe que contenha apenas
métodos abstratos. Embora uma classe não possa conter mais de uma super classe, a classe pode implementar mais
de uma interface. Exemplo:
public interface Pesado {

double obterPeso();
}
public interface Colorido {

Color obterCor();
}
public class Porco extends Animal implements Pesado, Colorido {

System.out.println("Óinc!");
}
//Implementação da interface Pesado

public double obterPeso() {
return 50.00;
}
//Implementação da interface Colorido

public Color obterCor() {
return Color.BLACK;
}
//Uma propriedade só do porco

public boolean enlameado() {
return true;
}
}
Classes internas
Java pode ter classes internas. Exemplos:
public class Cavalo extends Animal {

System.out.println("RIINCH!");
}
//Classe interna e privada. Existe só no contexto da classe
"Cavalo".
private class Parasita extends Animal {

System.out.println("SQRRT");
}
}
}
Objetos anônimos
Podemos ter também objetos anônimos, aonde não é necessário instanciar o objeto em uma variável para utilizá-lo.
Exemplo:
public class MostraBarulho {

public static void main(String args[]) {
new Cavalo().fazerBarulho(); //Objeto anônimo.
//Abaixo um objeto e classe anônimos!

new Animal() {//novo objeto
System.out.println("QUAC!");//imprime na tela
}
}.fazerBarulho();
}
}
Programas simples
Programa em Java para somar dois números inteiros:
import javax.swing.JOptionPane;
public class Soma{
public static void main(String[]args){
//declaração das variáveis

String numeroA, numeroB;
int numero1, numero2, soma;
//pede dois números inteiros

numeroA = JOptionPane.showInputDialog("Entre com o primeiro número
inteiro");
numeroB = JOptionPane.showInputDialog("Entre com o segundo número
inteiro");
//converte os números de string para inteiro

numero1 = Integer.parseInt(numeroA);
numero2 = Integer.parseInt(numeroB);
//outra forma de conversão seria utilizar o método valueOf

numero1 = Integer.valueOf(numeroA);
numero2 = Integer.valueOf(numeroB);
//efetua a soma dos números

soma = numero1 + numero2;
//mostra o resultado da soma para o usuário

JOptionPane.showMessageDialog(null,"A soma dos números é: " +
soma,"Resultado",JOptionPane.PLAIN_MESSAGE);
}
}
Extensões
Extensões em Java:
• J2ME (Micro-Edition for PDAs and cellular phones)
• J2SE (Standard Edition)
• J3D (A high level API for 3D graphics programming)
• JAAS (Java Authentication and Authorization Service)
• JAIN (Java API for Integrated Networks)
• Java Card
• JMX (Java Management Extensions)
• JavaFX
• JSF (JavaServer Faces)
• JSP (JavaServer Pages)
• JavaSpaces
• JCE (Java Cryptography Extension)
• JDBC (Java Database Connectivity)
• JDMK (Java Dynamic Management Kit)
• JDO (Java Data Objects)
• JEE (Enterprise Edition)
• Jini (a network architecture for the construction of distributed systems)
• Jiro
• JMF (Java Media Framework)
• JMI (Java Metadata Interface)
• JMS (Java Message Service)
• JNDI (Java Naming and Directory Interface)
• JNI (Java Native Interface)
• JOGL (A low level API for 3D graphics programming, using OpenGL)
• JSML (Java Speech API Markup Language)
• JXTA (open source-based peer-to-peer infrastructure)
• MARF (Modular Audio Recognition Framework)
• OSGi (Dynamic Service Management and Remote Maintenance)
• SuperWaba (JavaVMs for handhelds)
Polimorfismo
O Polimorfismo é uma característica muito importante em sistemas orientados a objetos. Termo proveniente do
grego que significa "muitas formas". Através dele conseguimos realizar várias tarefas.
Existem 4 tipos de polimorfismo divididos em 2 categorias (todos eles são implementados em Java), são descritos a
seguir:
Polimorfismo Universal
Como o próprio nome diz, ele é universal, ou seja, ele pode ser aplicado em vários casos, logo não consegue saber
quantas vezes será aplicado o polimorfismo. Trabalha potencialmente num conjunto infinito de tipos, de modo
disciplinado. Este polimorfismo possui duas formas:
Paramétrico ou parametrização
A idéia do polimorfismo universal paramétrico é ao definir um elemento(que pode ser uma classe, um método ou
alguma outra estrutura da linguagem), a definição do tipo sozinha ela é incompleta, ela precisa parametrizar este
tipo, ou seja, teoricamente não existiria o tipo sozinho, o que sim existe e o tipo de alguma coisa de alguma coisa,
por exemplo, uma list não seria só do tipo list, e sim do tipo list de elefantes. Vale lembrar que este polimorfismo só
foi implementado em Java apartir da versão 1.5.
Exemplo de Polimorfismo Paramétrico em Java
//Aqui no exemplo é criado um ArrayList do tipo ArrayList de Aluno, e

não ArrayList, isso é o polimorfismo universal paramétrico
ArrayList<Aluno> alunos = new ArrayList<Aluno>();//aqui ha o como aluno

Aluno a = new Aluno("Rafael");
alunos.add( a );
Aluno x = alunos.get( 0 );
System.out.println("Nome: "+ x.getNome() );
Inclusão
É quando você tem um ponteiro para mãe e ele consegue apontar para um objeto da filha, já que esse polimorfismo é
muito básico, é difícil você conseguir outras coisas sem ele, por isso boa parte das linguagens orientadas a objetos
conhecidas implementam esse polimorfismo.
Exemplo em Código:
class Porca {
int faces;
void acopleETorca();
}
class Porca8mm extends Porca {
void acopleETorca(){
if (...) ...
}
}
class Porca10mm extends Porca {
void acopleETorca(){
for (...) ...
}
}
Polimorfismo Ad-Hoc
É implementado quando queremos definir uma coisa específica, ou seja, este polimorfismo, diferente do universal,
não pode ser usado em todo lugar, logo sabemos quantas vezes ele será aplicado. Este polimorfismo possui duas
formas:
Sobrecarga (Overloading)
Permite que um “nome de função” seja utilizado mais de uma vez com diferentes assinaturas, ou seja, dois métodos
com o mesmo nome, porém com tipos de parâmetros diferentes por quantidades ou por tipo. O compilador
automaticamente chama a função “correta” que deve ser utilizada.
Exemplo em código: Podemos citar como exemplo uma função f aplicada aos parâmetros reais a e b, onde,
dependendo dos tipos dos parâmetros, podemos ter a execução da primeira ou da segunda função, caracterizando o
polimorfismo ad-hoc de overloading.
class Aritmetica{
int f (int x, int y) {
return x+y;
}
double f (double x, double y) {
return x*x + y*y;
}
}
class Testa{
public static void main(String[] args){
f(a,b);
}
}
Coerção
A idéia é que a linguagem é quem faz uma coerção de tipos e não o programador, ou seja, que esta não é feita
voluntariamente pelo programador e sim pela linguagem.
Exemplo: se o operador + é definido para somar dois números reais, e um número inteiro é passado como parâmetro
então o inteiro é "coergido" para real.
Exemplo em código:
class Funcionario {
protected String CPF, RG, telefone, nome;
}
class Gerente extends Funcionario {
private String departamento;
}
class Supervisor extends Funcionario {
private String setor;
}
class Auxiliar extends Funcionario {

}
public class TesteUpcasting {
Gerente ger = new Gerente();
Supervisor sup = new Supervisor();
Funcionario func = ger;
}
//func é do tipo Funcionario, mas recebe uma instância do tipo
Gerente - no caso ocorre um UPCASTING
}
Frameworks
É possível utilizar frameworks para facilitar o desenvolvimento de aplicações. Dentre os mais utilizados pode-se
destacar:
• Hibernate ferramenta para ORM;
• Junit ferramenta para auxiliar na criação de testes unitários;
• Log4j ferramenta para facilitar a criação de logs na aplicação;
• Spring ferramenta que auxilia principalmente implementação de injeção de dependências e inversão de controle;
• Struts controlador MVC (Model 2) web.
Ambientes de desenvolvimento
É possível desenvolver aplicações em Java através de vários ambientes de desenvolvimento integrado (IDEs). Dentre
as opções mais utilizadas pode-se destacar:
• BlueJ — um ambiente desenvolvido por uma faculdade australiana (considerado muito bom para iniciantes);
• JCreator — (gratuito/shareware) — um ambiente desenvolvido pela Xinox (recomendado para programadores
iniciantes);
• jEdit — (recomendado para programadores iniciantes);
IDEs completas (recomendado para programadores profissionais):
• Eclipse — um projeto aberto iniciado pela IBM;
• IntelliJ IDEA (comercial) — uma IDE desenvolvida pela JetBrains;
• JBuilder — um ambiente desenvolvido pela empresa Borland;
• JDeveloper (gratuito OTN) — uma IDE desenvolvida pela empresa Oracle;
• NetBeans (software livre) — uma IDE desenvolvida pela Sun Microsystems;
Outras IDEs (menos populares):
• Gel (IDE) — open source;
• Greenfoot — bem parecido com o BlueJ;
• JGRASP — bom para intermediários, feito pela equipe do Projeto GRASP;
• Java Studio Creator/Enterprise (gratuito SDN) um ambiente criado pela empresa Sun Microsystems;
• Workshop for WebLogic (comercial/desenvolvedor) um ambiente criado pela empresa Oracle;
• WebSphere Studio Application Developer um ambiente criado pela empresa IBM;
Certificações
Existem 8 tipos de certificações[7] da Sun Microsystems para Java:
• Sun Certified Enterprise Architect (SCEA)
• Sun Certified Mobile Application Developer (SCMAD)
• Sun Certified Developer For Java Web Services (SCDJWS)
• Sun Certified Business Component Developer (SCBCD)
• Sun Certified Web Component Developer (SCWCD)
• Sun Certified Java Developer (SCJD)
• Sun Certified Java Programmer (SCJP)
• Sun Certified Java Associate (SCJA)
Cada certificação testa algum tipo de habilidade dentro da plataforma e linguagem Java. Todos os testes são
realizados pela empresa Prometric[8] e são reconhecidos internacionalmente.
Comunidade
A comunidade de desenvolvedores Java reúne-se em grupo denominados JUGs (Java User Groups). No Brasil o
movimento de grupos de usuários expandiu-se bastante e tem formado alguns dos maiores grupos de usuários Java
do mundo[carece de fontes?], como por exemplo o PortalJava, GUJ e o JavaFree.
Licença
A Sun disponibiliza a maioria das distribuições Java gratuitamente e obtém receita com programas mais
especializados como o Java Enterprise System. Em 13 de novembro de 2006, a Sun liberou partes do Java como
software livre, sob a licença GNU General Public License.[9] A liberação completa do código fonte sob a GPL
ocorreu em maio de 2007.[10]
Curiosidades
O número mágico de uma classe Java, quando representado em Hexadecimal fica 0xCAFEBABE. Leia abaixo:
Patrick Naughton
—Strangely enough the magic number for .class files was chosen long before the name Java was ever uttered in reference to this language.
We were looking for something fun, unique and easy to remember. 0xcafebabe was better than the second runner-up, 0xdeadbabe. It is only
a coincidence that the oblique reference to the cute barristas at Peet's Coffee was foreshadowing for the name Java.
Ver também
• Java (plataforma de software)
[1] http:/ / www. sun. com/ 2004-0511/ feature/
[2] Java Study Group (http:/ / www. open-std. org/ JTC1/ SC22/ JSG/ )
[3] Why Java™ Was - Not - Standardized Twice (http:/ / csdl2. computer. org/ comp/ proceedings/ hicss/ 2001/ 0981/ 05/ 09815015. pdf)
[4] What is ECMA--and why Microsoft cares (http:/ / techupdate. zdnet. com/ techupdate/ stories/ main/ 0,14179,2832719,00. html)
[5] Java Community Process website (http:/ / www. jcp. org/ en/ home/ index)
[6] open.itworld.com - JAVAONE: Sun - The bulk of Java is open sourced (http:/ / open. itworld. com/ 4915/ 070508opsjava/ page_1. html)
[7] Java Certification (http:/ / www. sun. com/ training/ certification/ java/ index. xml)
[8] Prometric: Testing and Assessment (http:/ / www. prometric. com)
[9] Sun begins releasing Java under the GPL (http:/ / www. fsf. org/ news/ fsf-welcomes-gpl-java. html) (em inglês). Página visitada em 6 de
julho de 2010.
[10] JavaOne opening keynote notes and comments (http:/ / rollerweblogger. org/ roller/ entry/ javaone_opening_keynote_notes) (em inglês).
Página visitada em 6 de julho de 2010.
Ligações externas
• Página oficial da linguagem Java (http://java.sun.com/)
• Iniciando em Java (http://www.javafree.org/topic-850964-Iniciando-em-Java.html)
• Tutoriais oficiais da Sun (http://java.sun.com/docs/books/tutorial/)
• O que é Java? (http://www.javafree.org/artigo/871498/Tutorial-Java-O-que-e-Java.html)
• Características Básicas (http://www.javafree.org/artigo/871496/Tutorial-Java-2-Caracteristicas-Basicas.html)
• Orientação a Objetos com Java (http://www.javafree.org/artigo/871497/
Tutorial-Java-3-Orientacao-a-Objetos.html)
Padrão de projeto de software

Os padrões de projeto de software ou padrões de desenho de software, também muito conhecido pelo termo
original em inglês: Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de
sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução,
quando aplicar esta solução e suas conseqüências.
Os padrões de projeto visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do
software, sem considerar reutilização de código. Também acarretam um vocabulário comum de desenho, facilitando
comunicação, documentação e aprendizado dos sistemas de software.
História
O conceito de padrão de projeto foi criado na década de 70 pelo arquiteto Christopher Alexander.[1] [2] Em seus
livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, ele estabelece que um
padrão deve ter, idealmente, as seguintes características:
• Encapsulamento: um padrão encapsula um problema/solução bem definida. Ele deve ser independente,
específico e formulado de maneira a ficar claro onde ele se aplica.
• Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão.
• Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma
das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados
empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos
e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.
• Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.
• Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
• Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos
ou relacionados com padrões que endereçam problemas de nível mais baixo.
Além da definição das características de um padrão, Alexander definiu o formato que a descrição de um padrão deve
ter. Ele estabeleceu que um padrão deve ser descrito em cinco partes:
• Nome: uma descrição da solução, mais do que do problema ou do contexto.
• Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.
• Contexto: a descrição das situações sob as quais o padrão se aplica.
• Problema: uma descrição das forças e restrições envolvidos e como elas interagem.
• Solução: relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o
padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui
referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.
Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham
propuseram os primeiros padrões de projeto para a área da ciência da computação. Em um trabalho para a
conferência OOPSLA, eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk.[3] Nos
anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento destas idéias.
O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements of
Reusable Object-Oriented Software, publicado em 1995. Os autores desse livro são Erich Gamma, Richard Helm,
Ralph Johnson e John Vlissides, conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF".
Posteriormente, vários outros livros do estilo foram publicados, como Applying UML and Patterns: An Introduction
to Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto de padrões
conhecidos como GRASP (General Responsibility Assignment Software Patterns).
Padrões GoF
Os padrões "GoF" são organizados em famílias de padrões: de criação, estruturais e comportamentais. Os padrões de
criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os
comportamentais das interações e divisões de responsabilidades entre as classes ou objetos.
Um padrão "GoF" também é classificado segundo o seu escopo: de classe ou de objeto. Nos padrões com escopo de
classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos
padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de
execução.
Padrões "GoF" organizados nas suas famílias:
Padrões de criação
• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton
Padrões estruturais
• Adapter
• Bridge
• Composite
• Decorator
• Façade
• Flyweight
• Proxy
Padrões comportamentais
• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor
Padrões GRASP
• Controller
• Creator
• Expert
• Law of Demeter
• Low Coupling/High Cohesion
• Polymorphism
• Pure Fabrication
[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software.
1.ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2
[2] Doug Lea. Christopher Alexander:An Introduction for Object-Oriented Designers (http:/ / g. oswego. edu/ dl/ ca/ ca/ ca. html) (em Inglês).
Página visitada em 18 de abril de 2007.
[3] Kent Beck, Ward Cunningham. Using Pattern Languages for Object-Oriented Programs (http:/ / c2. com/ doc/ oopsla87. html) (em Inglês).
Página visitada em 18 de abril de 2007.
Bibliografia
• Christopher Alexander. Notes on the Synthesis of Form. Estados Unidos da América: Harvard University Press,
1964. ISBN 0-674-62751-2
• Christopher Alexander. The Timeless Way of Building. Estados Unidos da América: Oxford University Press,
1979. ISBN 0-19-502402-8
• Christopher Alexander. A Pattern Language. Estados Unidos da América: Oxford University Press, 1977. ISBN
0-19-501919-9
• Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and
Iterative Development. 1.ed. Estados Unidos da América: Prentice Hall, 2004. pp.736. ISBN 0-13-148906-2
• Gregor Hohpe, Bobby Woolf. Enterprise Integration Patterns: Designing, Building, And Deploying Messaging
Solutions. 1.ed. Estados Unidos da América: Addinson-Wesley, 2004. pp.659. ISBN 0-321-20068-3
• Pablo Dall'Oglio. PHP Programando com Orientação a Objetos (http://www.adianti.com.br/phpoo): Inclui
Design Patterns. 1.ed. São Paulo: Novatec, 2007. pp.576. ISBN 978-85-7522-137-2
• Alexandre Altair de Melo e Mauricio G. F. Nascimento. PHP Profissional (http://www.novatec.com.br/livros/
phppro): Aprenda a desenvolver sistemas profissionais orientados a objetos com padrões de projeto. 1.ed. São
Paulo: Novatec, 2007. pp.464. ISBN 978-85-7522-141-9
Ligações externas
• Lista de alguns padroes comuns (http://www.mindspring.com/~mgrand/pattern_synopses2.htm) (em inglês)
• Página com descrições e exemplos dos padrões GoF (http://www.vincehuston.org/dp/) (em inglês)
15
Padrões de Criação
Abstract Factory
Abstract Factory é um padrão de projeto de software (também conhecido como design pattern em inglês). Este
padrão permite a criação de famílias de objetos relacionados ou dependentes, através de uma única interface e sem
que a classe concreta seja especificada.
Utilização
O padrão Abstract Factory pode ser utilizado na implementação de um toolkit que disponibilize controles que
funcionam em diferentes interfaces gráficas, tal como Motif, GTK+ (GNOME) ou Qt (KDE). Estas GUIs possuem
diferentes padrões de controles visuais e, para facilitar a construção de aplicativos que interajam facilmente com
diferentes interfaces gráficas, é interessante que se defina interfaces comuns para acesso aos controles,
independentemente da GUI utilizada. Este problema pode ser resolvido através de uma classe abstrata que declara
uma interface genérica para criação dos controles visuais e de uma classe abstrata para criação de cada tipo de
controle. O comportamento específico, de cada um dos padrões tecnológicos contemplados, é implementado através
de uma classe concreta. O aplicativo, ou "cliente", interage com o toolkit através das classes abstratas sem ter
conhecimento da implementação das classes concretas.
Um exemplo bem simplista seria um projeto com interface para Mobile e para Desktop, uma boa opção para
reaproveitar os mesmos controles de interface seria criar pacotes com classes abstratas e os pacotes com as classes
concretas implementando apenas as diferenças. Esse padrão também se aplica na padronização de ambientes, por
exemplo, tamanhos de botões, fontes, cores de fundo, largura de bordas. Com isso e havendo uma política que exija
que os desenvolvedores usem essas classes em vez das nativas da linguagem, ajudará a padronizar a aparência e
comportamento das aplicações.
Exemplo
Neste exemplo, a classe abstrata WidgetFactory possui duas especializações: MotifWidgetFactory para widgets
Motif e QtWidgetFactory para widgets Qt. Essas especializações são classes concretas capazes de "produzir" os
elementos da interface gráfica. O cliente do toolkit obtém os elementos gráficos de que necessita através 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 Abstract Factory (no exemplo, a classe
Janela e a classe Botao).
Abstract Factory 16
Estrutura
Exemplo de Diagrama em UML para o Padrão Abstract Factory.
Código em Java
Este código, escrito na linguagem Java, mostra a implementação do diagrama mostrado acima. Por uma questão de
simplicidade, o código relacionado às janelas é omitido.
abstract class WidgetFactory

{
public static WidgetFactory obterFactory()
{
if( Configuracao.obterInterfaceGraficaAtual() ==
Configuracao.MotifWidget )
{
return new MotifWidgetFactory();
}
else
{
return new QtWidgetFactory();
}
}
public abstract Botao criarBotao();

}
class MotifWidgetFactory extends WidgetFactory

{
public Botao criarBotao() {
Abstract Factory 17
return new BotaoMotif();

}
}
class QtWidgetFactory extends WidgetFactory

{
public Botao criarBotao() {
return new BotaoQt();
}
}
abstract class Botao

{
public abstract void desenhar();
}
class BotaoMotif extends Botao

{
public void desenhar() {
System.out.println("Eu sou um botao Motif!");
}
}
class BotaoQt extends Botao

{
public void desenhar() {
System.out.println("Eu sou um botao Qt!");
}
}
public class Cliente

{
public static void main(String[] args)
{
WidgetFactory factory = WidgetFactory.obterFactory();
Botao botao = factory.criarBotao();

botao.desenhar();
}
}
Este exemplo imprimiria na tela o texto "Eu sou um botao Motif!" ou "Eu sou um botao Qt!" dependendo do valor
retornado pelo método Configuracao.obterInterfaceGraficaAtual(), que descobre a interface gráfica, Motif ou Qt,
utilizada pelo sistema.
Abstract Factory 18
Código em VB.NET
Public MustInherit Class WidgetFactory
Shared Function obterFactory() As WidgetFactory

If Configuracao.obterInterfaceGraficaAtual() Is
Configuracao.MotifWidget Then
Return New MotifWidgetFactory()
Else
Return New QtWidgetFactory()
End If
End Function
Public MustOverride Function criarBotao() As Botao
End Class
Public Class MotifWidgetFactory

Inherits WidgetFactory
Public Overrides Function criarBotao() As Botao

Return New BotaoMotif
End Function
End Class
Public Class QtWidgetFactory

Inherits WidgetFactory
Public Overrides Function criarBotao() As Botao

Return New BotaoQt
End Function
End Class
Public MustInherit Class Botao
Public MustOverride Sub desenhar()
End Class
Public Class BotaoMotif

Inherits Botao
Public Overrides Sub desenhar()

Console.Out.WriteLine("Eu sou um botão Motif.")
End Sub
End Class
Abstract Factory 19
Public Class BotaoQt

Inherits Botao
Public Overrides Sub desenhar()

Console.Out.WriteLine("Eu sou um botão Qt.")
End Sub
End Class
Public Class Client

Public Shared Sub main()
Dim factory As WidgetFactory = WidgetFactory.obterFactory
Dim botao As Botao = factory.criarBotao
botao.desenhar()
End Sub
End Class
Padrões relacionados
• Factory Method
• Prototype
• Singleton
Bibliografia
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable
Object-Oriented Software. 1.ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2
• Steven John Metsker. Padrões de Projeto Em Java. 1.ed. Brasil: Bookman, 2004. ISBN 85-363-0411-1
Builder 20
Builder
Builder é um padrão de projeto de software que permite a separação da construção de um objeto complexo da sua
representação, de forma que o mesmo processo de construção possa criar diferentes representações.
Estrutura
O padrão Builder, da forma como foi
descrito no livro Design Patterns:
Elements of Reusable Object-Oriented
Software, contém os seguintes
elementos:
• director — constrói um objeto
utilizando a interface do builder;
• builder — especifica uma interface Diagrama UML da estrutura do padrão Builder
para um construtor de partes do

objeto-produto;
• concrete builder — define uma implementação da interface builder, mantém a representação que cria e fornece
interface para recuperação do produto;
• product — o objeto complexo em construção. Inclui classes que definem as parte constituintes.
Utilização
O padrão Builder pode ser utilizado em uma aplicação que converte o formato RTF para uma série de outros
formatos e que permite a inclusão de suporte para conversão para outros formatos, sem a alteração do código fonte
do leitor de RTF.
A implementação da solução para esse problema pode ser realizada através de uma classe de leitura (director)
associada a uma classe capaz de converter o formato RTF para outra representação (builder). O objeto da classe de
leitura lê cada token do texto e executa o método apropriado no objeto de conversão, de acordo com tipo do token. A
classe de conversão possui um método para cada tipo de token, incluindo os caracteres comuns, parágrafos, fontes e
etc. Para cada formato de texto suportado é criada uma classe de conversão especializada (concrete builder). Um
conversor para formato ASCII, por exemplo, poderia ignorar qualquer requisição para converter tokens que não
fossem caracteres comuns. Um conversor para o formato PDF, por outro lado, iria processar qualquer requisição para
poder converter o estilo, além do texto.
Comparação com o Abstract Factory

O padrão Builder é muitas vezes comparado com o padrão Abstract Factory pois ambos podem ser utilizados para a
construção de objetos complexos. A principal diferença entre eles é que o Builder constrói objetos complexos passo
a passo e o Abstract Factory constrói famílias de objetos, simples ou complexos, de uma só vez.
Exemplo
Neste exemplo, o método lerRTF() (classe LeitorRTF) percorre uma lista com os tokens encontrados no texto de
entrada (formato RTF) e, para cada tipo de token, chama um método do objeto de tipo ConversorTexto. Dependendo
do formato escolhido para o texto de destino, será escolhida uma implementação da classe ConversorTexto:
ConversorPDF, ConversorTeX ou ConversorASCII. Cada uma destas classes implementa os métodos de acordo com
as características do formato relacionado. A classe ConversorASCII não implementa os métodos converteParagrafo()
Builder 21
e converteFonte() pois este formato (ASCII) não possui elementos de estilo.
Diagrama
Exemplo de Diagrama em UML para o Padrão Builder.
Código
Este código, escrito na linguagem Java, mostra a implementação do diagrama mostrado acima.
abstract class ConversorTexto {

public void converterCaractere(char c) {
// vazio
}
public void converterParagrafo() {

// vazio
}
public void converterFonte(Fonte f) {

// vazio
}
}
class ConversorPDF extends ConversorTexto {

System.out.print("Caractere PDF");
}

System.out.print("Parágrafo PDF");
}
Builder 22

System.out.print("Fonte PDF");
}
}
class ConversorTeX extends ConversorTexto {

System.out.print("Caractere Tex");
}

System.out.print("Paragrafo Tex");
}

System.out.print("Fonte Tex");
}
}
class ConversorASCII extends ConversorTexto {

System.out.print("Caractere ASCII");
}
}
class LeitorRTF {
private ConversorTexto conversor;
LeitorRTF(ConversorTexto c) {
this.conversor = c;
}
public void lerRTF() {
List<Token> tokens = obterTokensDoTexto();
for (Token t : tokens) {

if (t.getTipo() == Token.Tipo.CARACTERE) {
conversor.converterCaractere(t.getCaractere());
}
if (t.getTipo() == Token.Tipo.PARAGRAFO) {
conversor.converterParagrafo();
}
if (t.getTipo() == Token.Tipo.FONTE) {
conversor.converterFonte(t.getFonte());
Builder 23
}
}
}
}
public class Cliente {
ConversorTexto conversor;
if (args[0].equals("pdf")) {
conversor = new ConversorPDF();
} else if (args[0].equals("tex")) {
conversor = new ConversorTeX();
} else {
conversor = new ConversorASCII();
}
LeitorRTF leitor = new LeitorRTF(conversor);
leitor.lerRTF();
}
}
A classe Cliente determina, através do parâmetro passado ao programa Java ("pdf" para formato PDF, "tex" para Tex
e qualquer outro para ASCII), qual das classes derivadas de ConversorTexto irá utilizar na construção da classe
LeitorRTF.
• Composite
Bibliografia
Factory Method 24
Factory Method
Factory Method, na ciência da computação, é um padrão de projeto de software (design pattern, em inglês) que
fornece uma interface para criação de famílias de objetos relacionados ou dependentes, sem especificar suas classes
concretas. O factory method permite adiar a instanciação para as subclasses.
Estrutura
O padrão Factory Method, da forma
como foi descrito no livro Design
Patterns: Elements of Reusable
Object-Oriented Software, contém os
seguintes elementos:
• Creator — declara o factory method
(método de fabricação) que retorna
o objeto da classe Product
(produto). Este elemento também
pode definir uma implementação Diagrama UML da estrutura do padrão Factory Method
básica que retorna um objeto de
uma classe ConcreteProduct (produto concreto) básica;
• 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 implementação para a interface Product.
Utilização
Este padrão é muito utilizado em frameworks para definir e manter relacionamentos entre objetos. O framework
Spring, dependendo da configuração, pode utilizar um Factory Method para criar os seus beans.[1]
Este padrão pode ser utilizado na construção de um framework que suporta aplicações que apresentam múltiplos
documentos ao usuário. Normalmente este tipo de aplicação manipula um número variável de formatos de
documento e, por isso, este framework deve ser flexível o bastante para suportar qualquer formato. Uma solução para
este problema poderia disponibilizar, no framework, o código para alguns dos formatos mais utilizados. Mas, na
prática, esta solução seria uma implementação pouco flexível, e até mesmo incompleta, já que é custoso implementar
os mais variados formatos. O padrão Factory Method propõe uma solução que deixa para o cliente (a implementação
da aplicação) a tarefa de suportar os formatos necessários e para o framework o papel de definição de uma abstração
que oferece uma interface única para criação de documentos.
Este framework seria baseado em duas classes abstratas, que representam a Aplicação e o Documento. O cliente do
framework fornece um par de classes concretas, uma aplicação e o respectivo documento, para cada um dos formatos
de Documento suportados pela Aplicação. Se for necessário apresentar um documento que suporte desenho, por
exemplo, o cliente deve disponibilizar as classes AplicacaoDesenho e DocumentoDesenho (supondo que o sufixo
"Desenho" indique classes que suportam esta funcionalidade).
O objetivo do Factory Method está em diversas classes que implementam a mesma operação, retornarem o mesmo
tipo abstrato, mas internamente instanciam diferentes classes que o implementam. Com o Factory Method o criador
do objeto faz uma escolha de qual classe instanciar para o cliente. Para ser um Factory Method o método precisa
retornar (ou uma interface ou uma classe abstrata), e dependendo das necessidades do cliente criar um objeto
determinado como retorno. Um exemplo clássico do Factory Method são os iteradores tanto em Java como em .NET
Factory Method 25
Exemplo
Neste exemplo, uma aplicação, que é construída através de um framework baseado no padrão Factory Method,
suporta a criação de documentos do tipo MeuDocumento. O framework é constituído pelas classes abstratas
Aplicacao e Documento. A aplicação disponibiliza as classes concretas MinhaAplicacao e MeuDocumento. A classe
MinhaAplicacao é uma implementação da abstração definida pela classe Aplicacao.
Diagrama
Exemplo de Diagrama em UML para o Padrão Factory Method.
A chave deste padrão está na declaração do método abstrato criaDocumento, da classe Aplicacao, e na sua utilização
pelo método novoDocumento. Este arranjo permite que o método novoDocumento crie documentos sem conhecer os
detalhes de implementação, existentes em cada tipo de documento suportado pela aplicação. Isto permite que a
implementação do método criaDocumento (neste exemplo situada na classe MinhaAplicacao) varie livremente, para
atender os diversos formatos possivelmente suportados, sem que seja necessário modificar o código das classes
abstratas.
Código em Java
/**
* Abstração de uma Aplicação capaz de manipular
* documentos.
*/
abstract class Aplicacao {
private Documento doc;
/**
Factory Method 26
* Abstração do Factory Method

*/
abstract Documento criaDocumento();
void novoDocumento() {
this.doc = this.criaDocumento();
}
void abrirDocumento() {
this.doc.abrir();
}
}
/**
* Abstração 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 contém a implementação
* de uma aplicação capaz de manipular documentos
* do tipo MeuDocumento.
*/
class MinhaAplicacao extends Aplicacao {
/**
* Uma implementação do Factory Method. Este método é
* especializado na criação de documentos do tipo MeuDocumento
*/
Documento criaDocumento() {
return new MeuDocumento();
}
}
Factory Method 27
/**
* Esta classe concreta contém a implementação
* de um tipo de documento específico.
*/
class MeuDocumento extends Documento {
Código em VB.NET
O mesmo exemplo acima, em linguagem Visual Basic .NET.
Public MustInherit Class Aplicacao
Private doc As Documento
MustOverride Function criaDocumento() As Documento
Sub novoDocumento()
Me.doc = Me.criaDocumento
End Sub
Sub abrirDocumento()
Me.doc.abrir()
End Sub
End Class
Public MustInherit Class Documento
Sub abrir()
Console.WriteLine("Documento:Abrir documento!")
End Sub
Sub fechar()
Console.WriteLine("Documento:Fechar documento!")
End Sub
Sub gravar()
Console.WriteLine("Documento:Gravar documento!")
End Sub
End Class
Public Class MinhaAplicacao

Inherits Aplicacao
Public Overrides Function criaDocumento() As Documento

Factory Method 28
Return New MeuDocumento
End Function
End Class
Public Class MeuDocumento

Inherits Documento
End Class
Código em C#
O mesmo exemplo acima, em linguagem C#
public abstract class Aplicacao

{
private Documento doc;
Documento criaDocumento();
void novoDocumento()
{
this.doc = this.criaDocumento();
}
void abrirDocumento()
{
this.doc.abrir();
}
public abstract class Documento

{
void abrir()
{
Console.WriteLine("Documento:Abrir documento!");
}
void fechar()
{
Console.WriteLine("Documento:Fechar documento!");
}
void gravar()
{
Console.WriteLine("Documento:Gravar documento!");
}
Factory Method 29
public class MinhaAplicacao : Aplicacao

{
public Documento criaDocumento()
{
return new MeuDocumento();
}
}
public class MeuDocumento : Documento

{
• Template Method
• Prototype
[1] Rod Johnson, Juergen Hoeller, Alef Arendsen, Colin Sampaleanu, Rob Harrop, Thomas Risberg, Darren Davison, Dmitriy Kopylenko, Mark
Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Rick Evans. The Spring
Framework - Reference Documentation (http:/ / www. springframework. org/ docs/ reference/ beans.
html#beans-factory-class-instance-factory-method) (em Inglês). Página visitada em 16 de maio de 2007.
Bibliografia
• Steven John Metsker. Padrões de Projeto Em Java. 1.ed. Brasil: Bookman, 2004. ISBN 85-363-0411-1
Prototype 30
Prototype
Prototype, na ciência da computação, é um padrão de projeto de software (design pattern, em inglês) que permite a
criação de objetos a partir de um modelo original, ou protótipo.
Estrutura
O padrão Prototype, da forma como foi
descrito no livro Design Patterns:
Elements of Reusable Object-Oriented
Software, contém os seguintes
elementos:
• prototype — uma classe que declara
uma interface para objetos capazes
de clonar a si mesmo;
• prototype concreto —
implementação de um prototype;
Diagrama UML da estrutura do padrão Prototype
• cliente — cria um novo objeto
através de um prototype que é capaz
de clonar a si mesmo.
Efetivamente, cada objeto é, ele próprio, uma factory especializado em construir objetos iguais a si mesmo. O padrão
Prototype é utilizado freqüentemente em linguagens estaticamente tipadas como C++ e Java, e menos
freqüentemente utilizadas em linguagens dinamicamente tipadas como Smalltalk.
O padrão Prototype exige a implementação de uma operação de clonagem em cada uma das classes concretas do
protótipo. Esta tarefa pode ser inconveniente, no caso do reaproveitamento de classes pré-existentes que não
possuem tal operação, ou mesmo complexa, se for considerada a possibilidade de existirem referências circulares nos
atributos de um objeto (um objeto possui um atributo que referência um objeto que, por sua vez, referência o objeto
original).
Utilização
O padrão Prototype pode ser utilizado em sistemas que precisam ser independentes da forma como os seus
componentes são criados, compostos e representados. O padrão Prototype pode ser útil em sistemas com as seguintes
características:
• sistemas que utilizam classes definidas em tempo de execução;
• sistemas que utilizam o padrão Abstract Factory para criação de objetos. Neste caso, a hierarquia de classes pode
se tornar muito complexa e o padrão Prototype pode ser uma alternativa mais simples, por realizar a mesma tarefa
com um número reduzido de classes;
• sistemas que possuem componentes cujo estado inicial possui poucas variações e onde é conveniente
disponibilizar um conjunto pré-estabelecido de protótipos que dão origem aos objetos que compõem o sistema.
Quando utiliza o framework Spring, por exemplo, um desenvolvedor pode configurar um JavaBean como
"prototype". Esta configuração faz com que cada uma das referências a um JavaBean aponte para uma instância
diferente. O comportamento padrão, ou singleton, define que todas as referências a um JavaBean apontem para a
mesma instância de uma classe.[1]
Prototype 31
Exemplo
Neste exemplo é mostrado uma hierarquia de classes representando documentos de formato ASCII e PDF que são
criados através da classe Cliente. A partir de duas instâncias prototípicas, ascii e pdf, o método criarDocumento cria
clones de documentos de acordo com o tipo desejado. A tarefa de realizar a criação da instância é implementada na
classe Documento e herdada por suas classes filhas, ASCII e PDF.
Diagrama
Exemplo de Diagrama em UML para o Padrão Prototype.
Código
abstract class Documento implements Cloneable {
protected Documento clone() {

Object clone = null;
try {
clone = super.clone();
} catch (CloneNotSupportedException ex) {
ex.printStackTrace();
}
return (Documento) clone;
}
class ASCII extends Documento {
class PDF extends Documento {
}
Prototype 32
class Cliente {
static final int DOCUMENTO_TIPO_ASCII = 0;
static final int DOCUMENTO_TIPO_PDF = 1;
private Documento ascii = new ASCII();
private Documento pdf = new PDF();
public Documento criarDocumento(int tipo) {

if (tipo==Cliente.DOCUMENTO_TIPO_ASCII) {
return ascii.clone();
} else {
return pdf.clone();
}
}
}
Observação: Na linguagem Java, a interface Cloneable não possui métodos e é utilizada apenas para indicar que o
método Object.clone() pode realizar uma cópia, atributo por atributo, das instâncias de uma classe. [2]
Neste exemplo, a implementação da cópia da instância é delegada ao método clone da super classe Object (A classe
raiz da hierarquia de classes da linguagem Java). Se fosse necessário, as classes Documento, ASCII ou PDF
implementariam esse método para refletir algum comportamento específico.
• Composite
• Decorator
[1] Rod Johnson, Juergen Hoeller, Alef Arendsen, Colin Sampaleanu, Rob Harrop, Thomas Risberg, Darren Davison, Dmitriy Kopylenko, Mark
Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Rick Evans. The Spring
Framework - Reference Documentation (http:/ / www. springframework. org/ docs/ reference/ beans. html#beans-factory-scopes-prototype)
(em Inglês). Página visitada em 13 de junho de 2007.
[2] Sun Microsystems. JavaTM 2 Platform Std. Ed. (http:/ / java. sun. com/ j2se/ 1. 4. 2/ docs/ api/ java/ lang/ Cloneable. html) (em inglês).
Página visitada em 13 de junho de 2007.
Bibliografia
Singleton 33
Singleton
Singleton, é um padrão de projeto de software (do inglês Design
Pattern). Este padrão garante a existência de apenas uma instância de
uma classe, mantendo um ponto global de acesso ao seu objeto.
Nota linguística: O termo vem do significado em inglês quando se
resta apenas uma carta nas mãos, num jogo de baralho. Diagrama UML de uma classe singleton.
Muitos projetos necessitam que algumas classes tenham apenas uma

instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar
uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é
acessível unicamente através da classe singleton.
Exemplos
Em Java
Segue um exemplo em Java de classe Singleton usada em log de dados. Esta classe suporta inicialização sob
demanda e ambientes multi-thread.
public class SingletonLog {

// Construtor privado. Suprime o construtor público padrao.
private SingletonLog() {
// Leitura da configuração de log. Normalmente descrita em um
arquivo.
}
// Faz o log de eventos da aplicacao

public void doLog(String eventDescription) {
//Retorna a instância única da classe SingletonLog

public static SingletonLog getInstance() {
return SingletonLogHolder.instance;
}
//Classe auxiliar para criacao da instancia. Evita problemas de

sincronizacao de threads.
private static class SingletonLogHolder {
private static SingletonLog instance = new SingletonLog();
}
}
Singleton 34
Em C++
Segue um exemplo em C++ da implementação de uma classe Singleton:
class MyClass
{
private:
MyClass() {} //contructor padrão, não deve ser utilizado
isoladamente
public:
static MyClass& getInstance()
{
static MyClass *instance = 0;
if (!instance) instance = new MyClass();
return *instance;
}
};
Em Delphi
Abaixo segue um exemplo de como implementar uma classe Singleton:
Por exemplo, numa classe Fachada, onde se encontra todos os métodos disponíveis para a interface da aplicação,
pode ser criado um método dinâmico para que todos os que visualizam essa classe, não criarem mais instâncias da
mesma.
class function TFachada.ObterInstancia: TFachada;

begin
If FInstance = nil Then
FInstance := Cliente.Fachada.TFachada.Create();//objeto
instanciado através do Finstance
Result := FInstance;//retorna o objeto
end;
Em PHP
<?php
class Singleton
{
private static $_instance;
// Evita que a classe seja instanciada publicamente

private function __construct() { }
// Evita que a classe seja clonada

private function __clone() { }
public static function getInstance()

{
if (!isset(self::$_instance)) { // Testa se há instância
Singleton 35
definifa na propriedade, caso sim, a classe não será instanciada

novamente.
self::$_instance = new self; // o new self cria uma
instância da própria classe à própria classe.
}
return self::$_instance;
}
}
Em Ruby
class Klass
include Singleton
end
Em VB.NET
Public Class MyClass
Private Shared _instancia As MyClass
Private Shared objetoSincronia As New Object
Private Sub New()

End Sub
Public Shared Function getInstancia() As MyClass

If _instancia Is Nothing Then
SyncLock objetoSincronia
If _instancia Is Nothing Then _instancia = New MyClass
End SyncLock
End If
Return _instancia
End Function
End Class
Em ActionScript 3
package{
public class ExemploSingleton {
private static var instance:ExemploSingleton;
public function
ExemploSingleton(enforcer:SingletonEnforcer) : void {
if (enforcer == null)
throw new Error("Só pode haver uma instância de
ExemploSingleton");
}
public static function getInstance() : ExemploSingleton {

if (instance == null)
Singleton 36
instance = new ExemploSingleton( new

SingletonEnforcer );
return instance;
}
}
}
//Para bloquear o acesso ao constructor.
class SingletonEnforcer {
Em JavaScript
function Page(){
var width = 800;
this.getWidth = function(){
return width;
}
}
Page.instance = null;
Page.getInstance = function(){
if (Page.instance == null) Page.instance = new Page();
return Page.instance;
}
document.write( Page.getInstance().getWidth() );
Em c# (utilizando Generics)
public sealed class GenericSingleton<T> where T : class, new()
{
private static T _instance;
public static T GetInstance()

{
lock (typeof(T))
{
if (_instance == null)
_instance = new T();
return _instance;
}
}
}
// Teste do padrão Singleton

public class Car { public int Color { get; set; } }
public class Person { public string Name { get; set; } }
Singleton 37
class Program
{
static void Main(string[] args)
{
Car car = GenericSingleton<Car>.GetInstance();
car.Color = 1;
Person per = GenericSingleton<Person>.GetInstance();

per.Name = "John";
Car car2 = GenericSingleton<Car>.GetInstance();

car.Color = 2;
}
}
Obs: Esta solução não impede a criação de múltiplas instâncias das classes Car e Person. Como a classe genérica
GenericSingleton obriga que as classes passadas no parâmetro T tenham um construtor público, é possível criar
instâncias em qualquer trecho de código através de construções do tipo: Car car3 = new Car();.
38
Padrões Estruturais
Adapter
Adapter, também conhecido como Wrapper, é um padrão de projeto de software ou de desenho (do inglês design
pattern). Este padrão é utilizado para 'adaptar' a interface de uma classe. O Adapter permite que classes com
interfaces incompatíveis possam interagir.
Adapter permite que um objeto cliente utilize serviços de outros objetos com interfaces diferentes por meio de uma
interface única.
Bridge (padrão de projeto de software) 39
Bridge (padrão de projeto de software)

Bridge é um padrão de projeto de software, ou design pattern em inglês, utilizado quando é desejável que uma
interface (abstração) possa variar independentemente das suas implementações.
Imagine um sistema gráfico de janelas que deve ser portável para diversas plataformas. Neste sistema são
encontrados diversos tipos de janelas, como ícones, diálogos, etc. Estas janelas formam uma hierarquia que contém
uma abstração das janelas (classe base). Normalmente, a portabilidade seria obtida criando-se especializações dos
tipos de janelas para cada uma das plataformas suportadas. O problema com essa solução reside na complexidade da
hierarquia gerada e na dependência de plataforma que existirá nos clientes do sistema.
Através do padrão Bridge, a hierarquia que define os tipos de janelas é separada da hierarquia que contém a
implementação. Desta forma todas as operações de Janela são abstratas e suas implementações são escondidas dos
clientes.
Exemplo
O diagrama mostra a solução para o problema citado. Temos duas hierarquias de classes relacionadas: a hierarquia
de tipos de janelas (Janela, Icone e Dialogo) e a de implementação nas plataformas suportadas (JanelaImpl,
XWindowImpl e MSWindowImpl). O relacionamento entre as interfaces, Janela e JanelaImpl, é a "ponte" que
"desacopla" a interface da implementação. Para que um ícone seja desenhado, faz-se uma chamada ao método
DesenhaBorda() que por sua vez realiza "n" chamadas ao método DesenhaLinha() da classe XWindowImpl ou
MSWindowImpl, dependendo da plataforma desejada.
Exemplo de Diagrama em UML para o Padrão Bridge.

Composite 40
Composite
Composite é um padrão de projeto de software utilizado para representar um objeto que é constituído pela
composição de objetos similares a ele. Neste padrão, o objeto composto possui um conjunto de outros objetos que
estão na mesma hierarquia de classes a que ele pertence. O padrão composite é normalmente utilizado para
representar listas recorrentes - ou recursivas - de elementos. Além disso, esta forma de representar elementos
compostos em uma hierarquia de classes permite que os elementos contidos em um objeto composto sejam tratados
como se fossem um único objeto. Desta forma, todos os métodos comuns às classes que representam objetos
atômicos da hierarquia poderão ser aplicáveis também ao conjunto de objetos agrupados no objeto composto.
Aplicação
Utilizado sempre que é necessário representar elementos que são compostos por outros elementos similares.
Por exemplo, em interfaces gráficas um elemento gráfico pode ser constituído pela composição de vários outros
elementos gráficos. Uma janela pode conter um ou mais ícones, uma caixa de texto e vários outros elementos
gráficos - até mesmo outra janela. Considerando que uma determinada hierarquia de classes indicasse
ElementoGráfico como a super-classe comum a todas classes que representassem os elementos gráficos atômicos, a
classe Janela seria representada como uma classe que contém zero (0) ou mais elementos gráficos. Veja diagrama a
seguir.
Outro exemplo clássico é o de gramáticas utilizadas para definir linguagens de programação. Se utilizarmos uma
hierarquia de classes para representar os comandos da linguagem, supondo que a super-classe seria Comando,
teríamos uma classe para o comando de atribuição, outro para, digamos, o comando While, outra para o comando
composto - comando que é constituído por uma lista de outros comandos normalmente delimitados por indicadores
como { e } ou palavras reservadas como begin e end - e assim por diante. Pois bem, comandos que podem conter
outros comandos - como o comando composto ou o comando While do exemplo - normalmente serão representados
utilizando-se o padrão composite. Também é apresentado um diagrama a seguir que representa esta hierarquia.
É importante observar que será responsabilidade do objeto composto, para cada método a ser aplicável à lista de
objetos que possui, implementá-lo de maneira repetitiva. Por exemplo, no caso da hierarquia de elementos gráficos
exemplificada, suponha que um objeto cliente ative o método desenha() de um objeto do tipo Janela. Este método
deverá ser capaz de ativar os métodos desenha() de cada um dos objetos que ele contém. Desta maneira será possível
interagir com uma composição de objetos da mesma forma que se interage com objetos individuais.
Estrutura
O diagrama abaixo mostra a estrutura de classes do exemplo de componentes gráficos apresentada acima.
Hierarquia de Classes para Elemento Gráfico
Ressalte-se aí que a estrutura do padrão composite é sempre composta por uma estrutura auto-referenciada como a
do diagrama. O próximo diagrama representa a hierarquia de classes do exemplo de comandos da linguagem de
programação hipotética apresentada.
Composite 41
Hierarquia de Classes para Comando
• Decorator
• Flyweight
• Iterator
• Visitor
Bibliografia
Object-Oriented Software. 1.ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0201633612
Decorator
1. REDIRECIONAMENTO Padrão de projeto de software
Façade 42
Façade
Em padrões de projeto de software, um façade (fachada em francês) é um objeto que disponibiliza uma interface
para uma grande quantidade de funcionalidades de uma API, por exemplo. Um façade pode:
• tornar uma biblioteca de software mais fácil de entender e usar;
• tornar o código que utiliza esta biblioteca mais fácil de entender;
• reduzir as dependências em relação às características internas de uma biblioteca, trazendo flexibilidade no
desenvolvimento do sistema;
• envolver uma interface mal desenhada, com uma interface melhor definida.
Um façade é um padrão de projeto (design pattern) do tipo estrutural. Os façades são muito comuns em projeto
orientados a objeto. Por exemplo, a biblioteca padrão da linguagem Java contém dúzias de classes para
processamento do arquivo fonte de um caractere, geração do seu desenho geométrico e dos pixels que formam este
caractere. Entretanto, a maioria dos programadores Java não se preocupam com esses detalhes, pois a biblioteca
contém as classes do tipo façade (Font e Graphics) que oferecem métodos simples para as operações relacionadas
com fontes.
Ligações externas
• Descrição do padrão façade [1] (em inglês)
• Descrição do padrão façade [2] por Vince Huston (em inglês)
• Descrição do padrão façade na linguagem Java [3] (em inglês)
Referências
[1] http:/ / c2. com/ cgi/ wiki?FacadePattern
[2] http:/ / home. earthlink. net/ ~huston2/ dp/ facade. html
[3] http:/ / www. allapplabs. com/ java_design_patterns/ facade_pattern. htm
Flyweight 43
Flyweight
Flyweight é um padrão de projeto de software apropriado quando vários objetos devem ser manipulados, e esses não
suportam dados adicionais. No padrão flyweight não existem ponteiros para os métodos do dado, pois isto consome
muita memória. Em contrapartida são chamadas sub-rotinas diretamente para acessar o dado.
Um exemplo é o processador de texto. Cada caractere representa um objeto que possui uma família de fonte, um
tamanho de fonte e outras informações sobre o símbolo. Como imaginado, um documento grande com tal estrutura
de dados facilmente ocuparia toda a memória disponível no sistema. Para resolver o problema, como muitas dessas
informações são repetidas, o flyweight é usado para reduzir os dados. Cada objeto de caractere contém uma
referência para outro objeto com suas respectivas propriedades.
Ligações externas
• [Exemplo de implementação de FlyWeight para gerenciamento de recursos em jogos Título não preenchido, favor
adicionar] (em português)
Proxy (padrões de projeto)

Em programação, o padrão proxy é um padrão de projeto de software.
Um proxy, em sua forma mais geral, é uma classe que funciona como uma interface para outra classe. A classe proxy
poderia conectar-se a qualquer coisa: uma conexão de rede, um objeto grande em memória, um arquivo, ou algum
recurso que é difícil ou impossível de ser duplicado.
Um exemplo bem conhecido do padrão proxy é um objeto ponteiro de referência de contagem.
Em situações onde múltiplas cópias de um objeto complexo deve existir o padrão proxy pode ser adaptado para
incorporar o padrão flyweight a fim de reduzir o rastro de memória das aplicações. Normalmente uma instância de
um objeto complexo é criada e vários objetos proxies são criados, todos contendo uma referência ao único objeto
complexo original. Quaisquer operações realizadas nos proxies são enviadas ao objeto original. Uma vez que todas
as instâncias do proxy estiverem fora do escopo, a memória do objeto complexo pode ser desalocada.
Exemplo
O seguinte exemplo em Java ilustra o padrão "proxy virtual". A classe ImagemProxy é utilizada para acessar um
método remoto.
import java.util.*;
interface Imagem {
public void mostrarImagem();
}
// no Sistema A
class ImagemReal implements Imagem {
private String nomeDoArquivo;
public ImagemReal(String nomeDoArquivo) {
this.nomeDoArquivo = nomeDoArquivo;
carregarImagemDoDisco();
private void carregarImagemDoDisco() {

System.out.println("Carregando " + nomeDoArquivo);
}
public void mostrarImagem() {

System.out.println("Mostrando " + nomeDoArquivo);
}
}
// no Sistema B
class ImagemProxy implements Imagem {
private String nomeDoArquivo;
private Imagem imagem;
public ImagemProxy(String nomeDoArquivo) {

this.nomeDoArquivo = nomeDoArquivo;
}
public void mostrarImagem() {
imagem = new ImagemReal(nomeDoArquivo);
imagem.mostrarImagem();
}
}
class ExemploProxy {
Imagem imagem1 = new ImagemProxy("ResOi_10MB_Foto1");
Imagem imagem2 = new ImagemProxy("ResOi_10MB_Foto2");
imagem1.mostrarImagem(); // necessário o carregamento

imagem2.mostrarImagem(); // necessário o carregamento
}
}
A saída do programa é:
Carregando ResOi_10MB_Foto1
Mostrando ResOi_10MB_Foto1
Carregando ResOi_10MB_Foto2
Mostrando ResOi_10MB_Foto2
Ver também
• Padrão Composite
• Padrão Decorator
• Inicialização Lazy
46
Padrões Comportamentais
Chain of Responsibility
O padrão de projeto de software Chain of Responsibility representa um encadeamento de objetos receptores para o
processamento de uma série de solicitações diferentes. Esses objetos receptores passam a solicitação ao longo da
cadeia até que um ou vários objetos a tratem.
Cada objeto receptor possui uma lógica descrevendo os tipos de solicitação que é capaz de processar e como passar
adiante aquelas que requeiram processamento por outros receptores. A delegação das solicitações pode formar uma
árvore de recursão, com um mecanismo especial para inserção de novos receptores no final da cadeia existente.
Dessa forma, fornece um acoplamento mais fraco por evitar a associação explícita do remetente de uma solicitação
ao seu receptor e dar a mais de um objeto a oportunidade de tratar a solicitação.
Um exemplo da aplicação desse padrão é o mecanismo de herança nas linguagens orientadas a objeto: um método
chamado em um objeto é buscado na classe que implementa o objeto e, se não encontrado, na superclasse dessa
classe, de maneira recursiva.
Situações de utilização
• mais de um objeto pode tratar uma solicitação e o objeto que a tratará não é conhecido a priori;
• o objeto que trata a solicitação deve ser escolhido automaticamente;
• deve-se emitir uma solicitação para um dentre vários objetos, sem especificar explicitamente o receptor;
• o conjunto de objetos que pode tratar uma solicitação deveria ser especificado dinamicamente.
Ligações externas
• Referência a Chain of Responsibility no portal de padrões de projeto da Profa. Simone Nasser Matos
(CEFET-PR) [1] (em português)
• Exemplos de utilização de Chain of Responsibility no blog Cotidiano em Wonderland [2] (em português)
Referências
[1] http:/ / www. pg. cefetpr. br/ coinf/ simone/ patterns/ chain. php
[2] http:/ / rfiume. blogspot. com/ 2007/ 01/ chain-of-responsability. html
Command 47
Command
Command é um dos 23 padrões de projeto do GOF e é um dos 11 padrões comportamentais
Objetivo
Encapsular uma solicitação como um objeto, desta forma permitindo que clientes parametrizem diferentes
solicitações, enfileirem ou façam o registro (log) de solicitações e suportem operações que podem ser desfeitas.
Problema
Algumas vezes é necessário emitir solicitações para objetos nada sabendo sobre a operação que está sendo solicitada
ou sobre o receptor da mesma.
Utilizar quando:
• Parametrizar objetos por uma ação a ser executada. Você pode expressar tal parametrização numa linguagem
procedural através de uma função callback, ou seja, uma função que é registrada em algum lugar para ser
chamada em um momento mais adiante. Os Commands são uma substituição orientada a objetos para callbacks;
• Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command pode ter um tempo de
vida independente da solicitação original. Se o receptor de uma solicitação pode ser representado de uma maneira
independente do espaço de endereçamento, então você pode transferir um objeto Command para a solicitação
para um processo diferente e lá atender a solicitação;
• Suportar desfazer operações. A operação Execute, de Command, pode armazenar estados para reverter seus
efeitos no próprio comando. A interface do Command deve ter acrescentada uma operação Unexecute, que o
reverte.efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma lista
histórica. O nível ilimitado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente,
chamando operações Unexecute e Execute, respectivamente.
Aplicação
A chave deste padrão è uma classe abstrata Command, a qual declara uma interface para execução de operações. Na
sua forma mais simples, esta interface inclui uma operação abstrata Execute. As subclasses concretas de Command
especificam um par receptor-ação através do armazenamento do receptor como uma variável de instância e pela
implementação de Execute para invocar a solicitação. O receptor tem o conhecimento necessário para poder executar
a solicitação.
Sinônimos
Também conhecido como Action, Transaction (Ação, Transação, respectivamente).
Interpreter 48
Interpreter
Interpreter é mais um padrão de projeto (design patterns)
Gramáticas simples não precisam ser interpretadas por códigos criados através de geradores de analisadores
sintáticos. Para isso, podemos criar uma simples hierarquia de classes baseada na gramática que, através de recursão,
devolve a interpretação do código de entrada. É justamente isso que apresenta o padrão Interpreter: uma solução
elegante na interpretação de pequenas gramáticas.
Iterator
Iterator, em programação de computadores, permite a "iteração" e um modo de acesso a elementos de um agregado
de objetos, sequencialmente, sem exposição de estruturas internas.
Um exemplo: Considere uma lista simplesmente encadeada. Um iterador deve permitir o acesso a todos os elementos
da lista de uma forma segura sem que ocorra perda de informação ou modificações não permitidas.
Mediator
Um mediador, em linguagem de programação de computadores, é quem desacopla e gerencia as colaborações entre
um grupo de objetos. Define um objeto que encapsula as interações dentre desse grupo.
É um dos 23 padrões de projetos descritos para reutilização de softwares orientados a objetos. Ele permite a
unificação da interface de um sistema. Esse padrão é considerado um padrão comportamental devido à maneira
como ele pode alterar a execução do software.
Normalmente, um programa é feito por um número muito grande de classes. Então, a lógica e o código são
distribuídos entre essas classes. No entanto, quanto mais classes houver no seu projeto, a comunicação entre essas
classes será mais complexa. Isso faz com que a leitura e a manutenção do programa fique mais difícil, tal situação
acarreta na dificuldade de mudanças no projeto, já que, uma simples mudança pode afetar todo o código e as outras
classes.
Com o padrão mediator, a comunicação entre os objetos é encapsulada com um objeto mediador. Isso reduz a
dependência entre os objetos que estão se comunicando.
Exemplo
//Colleague interface
interface Command {
void execute();
}
//Concrete mediator
class Mediator {
BtnView btnView;
BtnSearch btnSearch;
BtnBook btnBook;
LblDisplay show;
Mediator 49
//....
void registerView(BtnView v) {
btnView = v;
}
void registerSearch(BtnSearch s) {
btnSearch = s;
}
void registerBook(BtnBook b) {
btnBook = b;
}
void registerDisplay(LblDisplay d) {
show = d;
}
void book() {
btnBook.setEnabled(false);
btnView.setEnabled(true);
btnSearch.setEnabled(true);
show.setText("booking…");
}
void view() {
btnView.setEnabled(false);
btnSearch.setEnabled(true);
btnBook.setEnabled(true);
show.setText("viewing…");
}
void search() {
btnSearch.setEnabled(false);
btnView.setEnabled(true);
btnBook.setEnabled(true);
show.setText("searching…");
}
//A concrete colleague

class BtnView extends JButton implements Command {
Mediator med;
BtnView(ActionListener al, Mediator m) {

Mediator 50
super("View");
addActionListener(al);
med = m;
med.registerView(this);
}
public void execute() {

med.view();
}

class BtnSearch extends JButton implements Command {
Mediator med;
BtnSearch(ActionListener al, Mediator m) {

super("Search");
med = m;
med.registerSearch(this);
}

med.search();
}

class BtnBook extends JButton implements Command {
Mediator med;
BtnBook(ActionListener al, Mediator m) {

super("Book");
med = m;
med.registerBook(this);
}

med.book();
}
}
Mediator 51
class LblDisplay extends JLabel {
Mediator med;
LblDisplay(Mediator m) {
super("Just start…");
med = m;
med.registerDisplay(this);
setFont(new Font("Arial", Font.BOLD, 24));
}
class MediatorDemo extends JFrame implements ActionListener {
Mediator med = new Mediator();
MediatorDemo() {
JPanel p = new JPanel();
p.add(new BtnView(this, med));
p.add(new BtnBook(this, med));
p.add(new BtnSearch(this, med));
getContentPane().add(new LblDisplay(med), "North");
getContentPane().add(p, "South");
setSize(400, 200);
setVisible(true);
}
public void actionPerformed(ActionEvent ae) {

Command comd = (Command) ae.getSource();
comd.execute();
}

new MediatorDemo();
}
}
Mediator 52
Componentes
Mediator - define a interface para a comunicação entre objetos "amigos".
ConcreteMediator - implementa a interface e coordena a comunicação entre os objetos ligados.
ConcreteColleague - se comunica com outros objetos através do mediator
Memento (informática)
Memento é um padrão de projeto que permite armazenar o estado interno de um objeto em um determinado
momento, para que seja possível retorná-lo a este estado, caso necessário.
Três objetos estão envolvidos na implementação do padrão Memento.
• Originador é o objeto cujo estado se deseja capturar.
• Memento é o objeto definido dentro da classe Originador, com modificador de acesso privado, cujo estado do
objeto originador será armazenado.
• Cliente é o objeto que acessará o originador, e deseja desfazer qualquer mudança efetuada, caso necessário.
O cliente deve requisitar um objeto memento, antes de se valer do originador. Após efetuar as operações desejadas
no originador, o cliente devolve a este o objeto memento, caso deseje desfazer qualquer alteração.
O objeto memento não permite o acesso de qualquer classe além da classe originador. Assim, tal padrão mostra-se
útil por não violar o conceito de encapsulamento.
Observer
O Observer é um padrão de projeto de software que define uma dependência um-para-muitos entre objetos de modo
que quando um objeto muda o estado, todos seus dependentes sejam notificados e atualizados automaticamente.
Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro
objeto.
O padrão Observer é também chamado de Publisher-Subscriber, Event Generator e Dependents.
Motivação
Um objeto que possua agregações deve permitir que seus elementos sejam acessados sem que sua estrutura interna
seja exposta. De uma maneira geral pode-se desejar que estes elementos sejam percorridos em várias ordens.
Como garantir que objetos que dependem de outro objeto percebam as mudanças naquele objeto?
• Os observadores (observer) devem conhecer o objeto de interesse.
• O objeto de interesse (subject) deve notificar os observadores quando for atualizado.
Os objetos devem se interligar entre si de forma a que não se conheçam em tempo de compilação de forma a criar o
acoplamento e desfazê-lo a qualquer momento em tempo de execução. Solucionar isso fornece uma implementação
muito flexível de acoplamento de abstrações.
Observer 53
Aplicabilidade
O padrão Observer pode ser usado quando uma abstração tem dois aspectos, um dependente do outro. Encapsular
tais aspectos em objetos separados permite que variem e sejam reusados separadamente. Quando uma mudança a um
objeto requer mudanças a outros e você não sabe quantos outros objetos devem mudar ou quando um objeto deve ser
capaz de avisar outros sem fazer suposições sobre quem são os objetos. Em outras palavras, sem criar um
acoplamento forte entre os objetos.
State
O padrão de projeto state é usado para permitir que um objecto altere o seu comportamento quando o seu estado
muda. Ao utilizar este padrão, parecerá que o objeto mudou de classe.
O padrão State deve ser utilizado nas seguintes situações:
O comportamento de um objeto depende fortemente do seu estado e ele deve alterar o seu comportamento em tempo
de execução dependendo do estado. Os métodos têm instruções condicionais grandes em que as condições dependem
do estado do objecto. Este estado é normalmente representado por uma ou mais constantes do tipo enumerado.
Frequentemente, vários métodos contém esta mesma estrutura condicional. O padrão State coloca cada ramo da
instrução condicional numa classe separada. Desta forma, o estado do objecto pode ser tratado como um objecto ele
próprio, o qual pode variar.
Strategy
Strategy é um padrão de projeto de software (do inglês design pattern). O objetivo é representar uma operação a ser
realizada sobre os elementos de uma estrutura de objectos. O padrão Visitor permite definir novas operações sem
alterar as classes dos elementos sobre os quais opera. Definir uma família de algoritmos e encapsular cada algoritmo
como uma classe, permitindo assim que elas possam ter trocados entre si. Este padrão permite que o algoritmo possa
variar independentemente dos clientes que o utilizam.
Aplicação
Utilizar o padrão Strategy quando:
•um objecto deve ser parametrizado com um de vários algoritmos, os quais podem ser encapsulados e representados
por uma única interface.
Template Method 54
Template Method
Um Template Method auxilia na definição de um algoritmo com partes do mesmo definidos por Método abstratos.
As subclasses devem se responsabilizar por estas partes abstratas, deste algoritmo, que serão implementadas,
possivelmente de várias formas, ou seja, cada subclasse irá implementar à sua necessidade e oferecer um
comportamento concreto construindo todo o algoritmo.
O Template Method fornece uma estrutura fixa, de um algoritmo, esta parte fixa deve estar presente na superclasse,
sendo obrigatório uma classeAbstrata que possa conter um método concreto, pois em uma interface só é possível
conter métodos abstratos que definem um comportamento, esta é a vantagem de ser uma Classe Abstrata porque
também irá fornecer métodos abstratos às suas subclasses, que por sua vez herdam este método, por Herança
(programação), e devem implementar os métodos abstratos fornecendo um comportamento concreto aos métodos
que foram definidos como abstratos. Com isso certas partes, do algoritmo, serão preenchidos por implementações
que irão variar, ou seja, implementar um algoritmo em um método, postergando a definição de alguns passos do
algoritmo, para que outras classes possam redefiní-los.[1]
Estrutura
A representação do diagrama de classe no modelo da UML mostra como acontece físicamente a herança e quem fica
responsável pela implementação. A importância de um diagrama de classes é porque descreve os tipos de objetos
presentes no sistema e os vários tipos de relacionamentos estáticos existentes entre eles.[2]
Exemplo de Diagrama em UML para o Padrão TemplateMethod.

Template Method 55
Código Java
Uma abordagem diferente é ter o código fonte, cujo diagrama de classe está representado acima, seja fiel ao que está
sendo representado no diagrama UML.
package br.com.nc.architect.templatemethod;
public abstract class AbstractClass {
public final void templateMethod() {

System.out.println("AbstractClass.templateMethod()
called");
primitiveOperation1();
primitiveOperation2();
public abstract void primitiveOperation1();

public abstract void primitiveOperation2();
}
public class Concrete1 extends AbstractClass {
public void primitiveOperation1() {

System.out.println("Concrete1.primitiveOperation1()
called");
}

called");
}
}
public class Concrete2 extends AbstractClass {

called");
}

Template Method 56
called");
}
}
public class TestTemplateMethod {

System.out.println("Test TemplateMethod");
System.out.println("-------------------------");
AbstractClass class1 = new Concrete1();

AbstractClass class2 = new Concrete2();
class1.templateMethod();
class2.templateMethod();
}
}
Referências
[1] METSKER, Steven John. PADRÕES DE PROJETO EM JAVA, Pág. 197. 2004
[2] FOWLER, Martin. UML ESSENTIALS: um breve guia para a linguagem-padrão de modelagem de objetos. 3ª ed. pág 52. Porto
Alegre.Bookman. 2005.
Visitor 57
Visitor
Em programação orientada a objetos e engenharia de software, o visitor pattern é um padrão de projeto
comportamental. Representa uma operação a ser realizada sobre elementos da estrutura de um objeto. O Visitor
permite que se crie um nova operação sem que se mude a classe dos elementos sobre as quais ela opera. É uma
maneira de separar um algoritmo da estrutura de um objeto. Um resultado prático é a habilidade de adicionar novas
funcionalidades a estruturas de um objeto pré-existente sem a necessidade de modificá-las.
A idéia é usar uma classe de elementos como uma estrutura, sendo que cada uma delas possui um método cujo um
dos argumentos é um objeto do tipo visitor. Visitor é uma interface que possui um método visit() para cada classe de
elementos. O método accept() de uma classe de elementos invoca o método visit() de sua respectiva classe. Classes
visitor concretas distintas podem então ser escritas para implementar operações especiais.
O padrão Visitor é uma solução para separar o algoritmo da estrutura. Uma das vantagens desse padrão é a
habilidade de adicionar novas operações a uma estrutura já existente. Com ele, podemos ter a classe ObjetoSolido e
o comportamento de queda em uma classe Gravidade, separada da estrutura do ObjetoSolido. Isso é feito através de
uma interface, onde o objeto que vai executar esse método da classe do comportamento, passa uma referencia dela
mesmo junto dos parâmetros normais da classe. No caso desse exemplo, teríamos:
Visitor gravidade = new Gravidade(); //esse é o nosso visitor,

responsável pelo comportamento de queda.
Solido solido = new Solido("caixa"); //solido que recebera o
comportamento
solido.accept(gravidade); //recebe o comportamento Gravidade
Internamente, o método accept(Visitor visitor) de Solido faz o seguinte:
public void accept(Visitor visitor) {

visitor.visitSolido(this);
}
Ao passar para o Visitor uma referencia de si mesmo, o visitor pode acessar os métodos e atributos públicos dessa
classe, que no nosso caso, vai adicionar a aceleração da gravidade ao Solido. Assim como o comportamento de
queda foi adicionado, outros também poderiam ser feitos da mesma maneira, como movimentação através do
teclado, sons... as possibilidades são infinitas.
58
Ajax
AJAX (programação)
AJAX (acrônimo em língua inglesa de Asynchronous Javascript And XML) é o uso metodológico de tecnologias
como Javascript e XML, providas por navegadores, para tornar páginas Web mais interativas com o usuário,
utilizando-se de solicitações assíncronas de informações. Foi inicialmente desenvolvida pelo estudioso Jessé James
Garret e mais tarde por diversas associações.
Descrição
AJAX não é um novo modelo para desenvolvimento web. Os navegadores implementam essa tecnologia desde o ano
2000(no mínimo). Porém sua popularização nos últimos anos tem também trazido consigo muitas outras melhorias
para a Web. Tem estimulado a construção de aplicações Web mais dinâmicas e criativas. AJAX não é uma
tecnologia, mas um conjunto de tecnologias conhecidas trabalhando juntas, cada uma fazendo sua parte, oferecendo
novas funcionalidades. AJAX incorpora em seu modelo:
• Exposição e interação dinâmica usando o DOM;
• Intercâmbio e manipulação de dados usando XML e XSLT;
• Recuperação assíncrona de dados usando o objeto XMLHttpRequest e XMLHttpResponse;
• JavaScript fazendo a junção entre os elementos.
O modelo clássico de aplicação web trabalha assim: a maioria das ações do usuário na interface dispara uma
solicitação HTTP para o servidor web. O servidor processa algo, recuperando dados, realizando cálculos,
conversando com vários sistemas legados, e então retorna uma página HTML para o cliente. É um modelo adaptado
do uso original da Web como um agente de hipertexto, porém o que faz a web boa para hipertexto não
necessariamente a faz boa para aplicações de software.
Com a popularização de sistemas que funcionam inteiramente na Web e também com o aumento da velocidade das
conexões banda larga, o problema da espera pelo envio e retorno da página inteira se tornou muito mais evidente
para o usuário. Obviamente, se nós estivéssemos projetando a Web a partir do zero para aplicações, não faríamos
com que os usuários esperassem em vão. Uma vez que a interface está carregada, por que a interação do usuário
deveria parar a cada vez que a aplicação precisasse de algo do servidor? Na realidade, por que o usuário deveria ver a
aplicação ir ao servidor toda vez?
As principais vantagem das aplicações que utilizam AJAX para determinadas requisições é que os dados trafegados
pela rede são reduzidos e o usuário não precisa aguardar a página ser recarregada a cada interação com o servidor.
A popularização das tecnologias que o AJAX reúne, foi muito importante para a criação do conceito Web 2.0, que
até hoje gera grandes divisões entre os maiores pensadores da Web.
Apesar de não possuir nada inovador em sua essência, o uso de AJAX revolucionou a Web inteira trazendo a tona
muitos conceitos importantes para o desenvolvimento web.
Os quatro princípios de Ajax

O modelo clássico de aplicação baseado em páginas está relacionado com muitas das estruturas que nós usamos, e
também em nossas maneiras de pensar. Vamos fazer uma análise de alguns minutos para descobrir o que são estas
suposições essenciais e como necessitamos repensar estas idéias para entendermos Ajax suficientemente.
O navegador hospeda uma aplicação, e não conteúdo

Numa aplicação web clássica baseada em páginas, o navegador é efectivamente um terminal burro. Ele não sabe
nada sobre o que o utilizador está realmente realizando em suas ações conseqüentes. Todas essas informações são
retidas no servidor web, tipicamente na sessão do utilizador. Sessões de utilizador no lado servidor são comuns
atualmente. Se a aplicação foi escrita em PHP, Plataforma Java, .NET, Ruby on Rails ou outra linguagem utilizada
no desenvolvimento de aplicações para Web, a sessão no lado servidor faz parte da API padrão, assim como o
controle de solicitações, respostas, e tipos de conteúdo (MIME).
Quando o utilizador entra ou de outra maneira inicia uma sessão, vários objetos são criados no servidor,
representando, por exemplo, a cesta de compras e as credenciais de cliente do utilizador. Ao mesmo tempo, a página
inicial é servida ao navegador, em um fluxo de marcações HTML que mistura um anúncio de apresentação padrão e
dados específicos do utilizador juntos com o conteúdo, como por exemplo, uma lista de itens exibidos recentemente.
Toda vez que o utilizador interage com o sítio, um outro documento é enviado para o navegador, contendo a mesma
mistura de cabeçalhos e dados. O navegador retira o documento anterior e exibe o novo, porque ele não sabe que o
outro documento produz um resultado muito semelhante.
Quando o utilizador efetua a saída ou fecha o navegador, a aplicação sai e a sessão é destruída. Qualquer informação
que o utilizador necessite ver na próxima vez que ele entrar terá que ser passada para a camada de persistência de
dados em cada visita. Já em uma aplicação AJAX, parte da lógica da aplicação é movida para o navegador.
Neste novo cenário, quando o utilizador entra, um documento mais complexo é entregue ao navegador, uma grande
proporção do qual é código JavaScript. Este documento permanecerá com o utilizador por toda a sessão, ainda que
ele resolva provavelmente alterar sua aparência consideravelmente, enquanto o utilizador está interagindo com ele.
Ele sabe como responder às informações inseridas pelo utilizador e é capaz de decidir se manipula a entrada do
utilizador ele mesmo ou se passa uma solicitação para o servidor web (o qual tem acesso ao banco de dados do
sistema e outros recursos), ou ainda, se faz uma combinação de ambos.
Ele também pode armazenar o estado, porque o documento continua persistindo sobre toda a sessão do usuário. Por
exemplo, o conteúdo de uma cesta de compras pode ser armazenado no navegador, em vez de ser armazenado na
sessão do servidor.
O servidor fornece dados, e não conteúdo

Como observamos, uma aplicação web clássica oferece a mesma mistura de alegorias, conteúdos e dados em todos
os passos. Quando nosso usuário adiciona um item na cesta de compras, tudo que precisamos realmente é responder
com o valor atualizado da cesta ou informar se alguma coisa deu errado.
Um carrinho de compra baseado em Ajax pode comportar-se de forma mais inteligente, por meio de remessas de
solicitações assíncronas ao servidor. O cabeçalho, o histórico de navegação, e outras características do layout da
página estão todas carregadas, portanto o servidor necessita enviar de volta somente os dados relevantes.
Uma aplicação AJAX poderia fazer isto de vários modos, como por exemplo, devolver um fragmento de JavaScript,
um fluxo de texto simples, ou um pequeno documento XML. Nós mostraremos em detalhes as vantagens e
desvantagens de cada um, mais a frente. É suficiente dizer por agora que qualquer um destes formatos será muito
menor que a misturada de informações devolvida pela aplicação web clássica.
Em uma aplicação Ajax, o tráfego tem sua maior intensidade no início, com um largo e complexo cliente sendo
entregue em uma única explosão, quando o usuário entra. As comunicações subseqüentes com o servidor são muito
mais eficientes, de qualquer forma. Para uma aplicação breve, o tráfego cumulativo pode ser menor em uma
aplicação de página web convencional. Mas conforme o tamanho médio do tempo de interação aumentar, o custo de
largura de banda da aplicação Ajax torna-se menor do que sua aplicação clássica equivalente.
A interação do utilizador com a aplicação pode ser flexível e contínua

Um navegador web oferece duas maneiras de enviar entradas de dados para um outro computador: com os enlaces e
formulários HTML.
Os hyperlinks podem ser carregados com parâmetros CGI (Common Gateway Interface – Interface de Comunicação
Comum) apontando para páginas dinâmicas ou servlets. Eles podem estar vinculados com imagens e folhas de estilo
(CSS) para oferecer uma pequena melhoria na interface, como por exemplo, definir efeitos quando o mouse estiver
sobre eles.
Os controles de formulário oferecem um subconjunto básico de componentes padrões de interface com o usuário:
caixas de texto, caixas de checagem e botões de rádio, além de listas de seleção. Entretanto estes controles não são
suficientes. Não existem controles de seleção em árvores, grades para edição, ou caixas de combinação. Os
formulários, assim como os hyperlinks, apontam para URLs residentes no servidor.
Alternativamente, os hyperlinks e os controles de formulário podem apontar para funções JavaScript. Isto é uma
técnica comum em páginas web para prover uma validação de formulário rudimentar em JavaScript, verificando por
campos vazios, valores fora de intervalo, e assim por diante, antes de submeter os dados para o servidor. Estas
funções JavaScript existem somente enquanto a própria página existe e é substituída quando a página efetuar o seu
envio.
Enquanto a página está sendo enviada, o usuário aguarda a sua resposta. A página anterior pode ainda estar visível
por algum tempo, e o navegador pode até permitir que o usuário clique em qualquer um dos links visíveis, mas se
assim for feito, produzirá resultados imprevisíveis e até entornar em uma confusão com a sessão no servidor. O
usuário está normalmente aguardando a página ser atualizada que, frequentemente, possuem quase que as mesmas
informações que lhes foram apanhadas instantes atrás. Adicionando um par de calças à cesta de compras não é
razoável modificar as categorias em um nível acima por “roupas masculinas”, “roupas femininas”, “infantis” e
“acessórios”.
Voltemos ao exemplo do carrinho de compras novamente. Devido ao facto de que nosso carrinho de compras em
Ajax pode enviar dados assíncronamente, os utilizadores podem soltar os objectos dentro dele tão rápido quanto eles
podem clicar. Se o código de nosso carrinho no lado cliente for robusto, ele tratará esta tarefa facilmente, e os
usuários podem continuar com o que eles estão fazendo.
É claro que não existe nenhum carrinho para colocarmos as coisas, somente um objeto em sessão no servidor. Mas
os usuários não querem saber sobre objetos de sessão enquanto estão fazendo compras, e a metáfora do carrinho
provê uma descrição do mundo real mais confortável do que está acontecendo. Troca de contextos entre a metáfora e
o acesso direto ao computador é uma distração para usuários. Aguardar uma página ser atualizada levará o usuário à
realidade de estar sentado em um computador por um curto tempo, e nossa implementação em Ajax evita que isto
ocorra. Fazer compras é uma atividade transitória, mas se considerarmos um domínio de negócios diferente, por
exemplo, um cenário de assistência e atendimento intensivo ou uma tarefa de planejamento complexa, então o custo
de interrupção da seqüência de trabalho em alguns poucos segundos, com uma atualização de página, é algo inviável.
A segunda vantagem de Ajax é que podemos associar eventos a um maior número de ações do usuário. Os conceitos
mais sofisticados de interface com o usuário, assim como "arrastar e soltar", se tornam praticáveis, trazendo as
experiências dessas interfaces em pé de igualdade com os controles de aplicações desktop. Da perspectiva de
usabilidade, esta liberdade não é importante somente porque ela permite exercer nossa imaginação, mas porque ela
nos permite combinar a interação do usuário e as solicitações ao servidor de maneira mais completa.
Para comunicar com o servidor em uma aplicação web clássica, necessitamos clicar em um hyperlink ou submeter
um formulário, e então aguardar. No entanto, este método interrompe a interação com o usuário. Em contraste, a
possibilidade de se comunicar com o servidor em resposta a um movimento ou arraste do mouse, ou até quando
digitamos, habilita o servidor a trabalhar juntamente com o usuário. O Google Suggest é um exemplo muito simples
e efetivo disto: responder às teclas pressionadas enquanto ele digita dentro da caixa de pesquisa, e então, comunicar
com o servidor para recuperar e exibir uma lista de possíveis finalizações para as expressões, baseada nas pesquisas
feitas por outros usuários do mecanismo de busca em todo o mundo.
Real codificação requer disciplina

Neste momento, as clássicas aplicações web fazem uso de JavaScript em certas ocasiões, para adicionar
características avançadas e exageradas de um programa, agregando-as nas páginas. O modelo baseado em páginas
previne qualquer uma destas melhorias que consista em um atraso longo demais, o qual limita as utilidades para as
quais elas podem ser oferecidas. Isto fez com que JavaScript recebesse injustamente, uma reputação de algo banal –
por má sorte da linguagem – e não sendo bem vista pelos desenvolvedores sérios.
Codificar uma aplicação Ajax é algo completamente diferente. O código que você fornece quando os usuários
iniciam a aplicação deve executar até que eles encerrem-na, sem interrupção, sem diminuição de velocidade, e sem
produção de escapes de memória. Se estivermos mirando no mercado de aplicações poderosas, então temos em vista
muitas horas de intenso uso. Para atingirmos este objetivo, devemos escrever códigos de alto-desempenho, e
manuteníveis, usando a mesma disciplina e entendimento que é aplicado com sucesso às camadas do servidor.
A base de código será tipicamente mais ampla que qualquer código escrito para uma aplicação web clássica. Boas
práticas na construção da base de código se tornam muito importantes. O código deve tornar-se, de preferência,
responsabilidade de uma equipe do que apenas um indivíduo, criando edições de manutenibilidade, separações de
interesses, e estilos e padrões de codificação comum. Uma aplicação Ajax, portanto, é uma porção de código
funcionalmente complexa que comunica eficientemente com o servidor enquanto o usuário continua com seu
trabalho. Ela é claramente uma descendência da aplicação clássica baseada em páginas.
Algumas tecnologias que fazem uso de AJAX

• Google earth
• Google maps
• AWB
Ver também
• ExtJS, framework de código aberto em Javascript com objetos para implementação de aplicações em Ajax
• Mootools, framework de código aberto em Javascript para implementação de aplicações em Ajax
• Rico, framework de código aberto para implementação de aplicações em Ajax
• Prototype, framework de código aberto em Javascript com objetos para implementação de aplicações em Ajax
• Jquery, framework de código aberto em Javascript
• ScriptCase, framework para desenvolvimento de aplicações em PHP com Ajax
• EasyAjaxTool, [[Framework [1]] de Código Aberto] Ferramenta leve para usar ajax com qualquer linguagem de
servidor.
Ligações externas
• AJAX - Visão Conceitual [2]
• Cloning Google Suggest with AjaxAC [3]
• Ajax Tutorial [4] Get, post, text, XML.
• AJAX DWR tutorial [5]
• Wiki de padrões ajax (inglês) [6]
• AJAX Tool [1] Framework de Código Aberto leve para usar ajax com qualquer linguagem de servidor.
Referências
[1] http:/ / code. google. com/ p/ easyajaxtool/
[2] http:/ / portaljava. com/ jnuke/ bin/ / articles/ view?id=154_AJAX_-_Vis%E3o_Conceitual
[3] http:/ / www. phpriot. com/ d/ articles/ php/ application-design/ google-suggest-ajaxac/ index. html
[4] http:/ / www. xul. fr/ en-xml-ajax. html
[5] http:/ / soaagenda. com/ journal/ articulos/ el-mejor-ejemplo-dwr-o-el-mejor-tutorial-dwr/
[6] http:/ / ajaxpatterns. org/
63
JavaScript
JavaScript
JavaScript é uma linguagem de programação criada por Brendan Eich para a Netscape em 1995, que a princípio se
chamava LiveScript. A Netscape, após o sucesso inicial desta linguagem, recebeu uma colaboração considerável da
Sun, a qual possibilitou posteriormente dizer que o JavaScript é uma linguagem compatível com a linguagem
JavaWikipedia:Por favor seja claro, por esta razão, a semelhança dos nomes "JavaScript".
A linguagem foi criada para atender, principalmente, às seguintes necessidades:
• Validação de formulários no lado cliente (programa navegador);
• Interação com a página.
Assim, foi feita como uma linguagem de script. JavaScript tem sintaxe semelhante à do Java, mas é totalmente
diferente no conceito e no uso.
De acordo com seu sistema de tipos, o JavaScript é:
• fraca - sua tipagem é mutável;
• dinâmica - uma variável pode assumir vários tipos diferentes durante a execução;
• implícita - as variáveis são declaradas sem tipo.
1. É interpretada, ao invés de compilada;
2. Possui ótimas ferramentas padrão para listagens (como as linguagens de script, de modo geral);
3. Oferece bom suporte a expressões regulares (característica também comum a linguagens de script).
Sua união com o CSS é conhecida como DHTML. Usando o Javascript, é possível modificar dinamicamente os
estilos dos elementos da página em HTML.
Dada sua enorme versatilidade e utilidade ao lidar com ambientes em árvore (como um documento HTML), foi
criado a partir desta linguagem um padrão ECMA, o ECMA-262, também conhecido como ECMAScript. Este
padrão é seguido, por exemplo, pela linguagem ActionScript da Adobe(Antigamente Macromedia, porém a empresa
foi vendida à Adobe).
Além de uso em navegadores processando páginas HTML dinâmicas, o JavaScript é hoje usado também na
construção do navegador Mozilla, o qual oferece para a criação de sistemas GUI todo um conjunto de ferramentas
(em sua versão normal como navegador, sem a necessidade de nenhum software adicional), que incluem (e não
apenas) um interpretador de Javascript, um comunicador Javascript <-> C++ e um interpretador de XUL, linguagem
criada para definir a interface gráfica de aplicações.
O uso de JavaScript em páginas XHTML, pelo padrão W3C, deve ser informado ao navegador da seguinte forma:
<script type="text/javascript">
/* aqui fica o script */
</script>
Caso contrário, o navegador irá interpretar o script como sendo código HTML, escrevendo-o na página.
JavaScript 64
Exemplos de scripts
Scripts Simples
alert("Cuidado");
// Mostra um alerta de Sim ou Não.

if(confirm("Escolhe \"Sim\" ou \"Não\" para ver a mensagem
correspondente."))
{
alert("Mensagem 01"); // mostra um alerta para resposta OK
}
else
{
alert("Mensagem 02"); // mostra um alerta para resposta Cancelar
}
// escreve na barra de status do navegador

window.defaultStatus="Mensagem que será mostrada";
Comentários
Em Javascript, podemos utilizar comentários de duas formas
• Comentários de única linha;
• Comentários de múltiplas linhas.
Exemplos de comentários:
//Este comentário ocupa uma única linha
/*Já este comentário

pode utilizar várias
linhas*/
</script>
Funções
Criando uma função simples:
function nome_da_funcao() { //nome_da_funcao deve ser substituído pelo

nome da função que será colocada
window.alert('Função terminada'); // alerta que será exibido quando
a função for executada
}
Outra função simples:
function nome_da_funcao(atributos)
//nome_da_funcao deve ser
//substituído pelo nome da função que será colocada
{
JavaScript 65
// pedido de confirmação com os botões OK e Cancelar

confirm("Função terminada");
}
function nome_da_funcao(atributos) //nome_da_funcao deve ser

// substituído pelo nome da função que será colocada
{
if(confirm("Função terminada")) // pedido de confirmação com os
botões OK e Cancelar
{
alert("ok pressionado") //aparece se apertar ok
} else {
alert("cancelar pressionado") //aparece se apertar cancelar
}
}
// constructor function
function MyObject(attributeA, attributeB) {

this.attributeA = attributeA
this.attributeB = attributeB
}
// cria um Objeto chamado obj

obj = new MyObject('red', 1000);
// acessa um atributo do obj

alert(obj.attributeA);
// accessa um atributo com notação de array associativo

alert(obj["attributeA"]);
// adiciona um novo atributo

obj.attributeC = new Date();
// remove um atributo do obj

delete obj.attributeB;
// remove o Objeto inteiro

delete obj;
function Derive()
{
this.Override = function() {
alert("Derive::Override()");
}
}
JavaScript 66
Derive.prototype = new Base();
d = new Derive();
d.Override();
d.BaseFunction();
d.__proto__.Override(); // somente mozilla
//resultará na exposição:
Derive::Override()
Base::BaseFunction()
Base::Override() // somente mozilla
Hierarquia do objeto
function red() {
this.sayRed = function () {
alert ('red wine')
}
}
function blue() {
this.sayBlue = function () {
alert('blue sky')
}
this.someName = black // inherits black.someName()

this.someName()
// inherits black
}
function black () {
this.sayBlack = function () {
alert('black night')
}
}
function anyColour() {
this.anotherName = red // inherits red
this.anotherName() // inherits red
this.sayPink = function()
{
alert('"Any Colour You Like" is a song of Pink Floyd')
}
this.anotherName = blue // inherits blue ( + black )
this.anotherName() // inherits blue ( + black )
this.anotherName = 'released 1973' // now it's a string - just for
fun
JavaScript 67
function alert()
{
alert('Olá, Mundo!');
}
var caue = new anyColour()

caue.sayRed()
caue.sayBlue()
caue.sayBlack()
caue.sayPink()
alert(caue.anotherName)
Programa Olá Mundo

<html>
<head>
<title>Programa Olá Mundo</title>
</head>
<body>
document.write("Olá, Mundo!");
</script>
</body>
</html>
Hello World em caixa de diálogo

<html>
<head>
<title>Programa Olá Mundo</title>
</head>
<body>
window.alert("Olá, Mundo!");
</script>
</body>
</html>
Números Perfeitos
<html>
<head>
<title>Números Perfeitos</title>
</head>
<body>
var MAX = 30000;
JavaScript 68
var som = 0;
var n = 2;
var i;
while (n < MAX)

{
var metade = n / 2;
for (i = 1; i <= metade; i++)

{
if ((n % i) == 0)
{
som+=i;
}
}
if (som == n)
{
document.write("Numero Perfeito = "+n + "<br />");
som=0;
n++;
}
}
</script>
</body>
</html>
Pop-up não bloqueável

<html>
<head>
<title></title>
<style type="text/css">
#popup{
position: absolute;
top: 30%;
left: 30%;
width: 300px;
height: 150px;
padding: 20px 20px 20px 20px;
border-width: 2px;
border-style: solid;
background: #ffffa0;
display: none;
}
</style>
JavaScript 69
function fechar(){
document.getElementById('popup').style.display = 'none';
}
function abrir(){
document.getElementById('popup').style.display = 'block';
setTimeout ("fechar()", 3000);
}
</script>
</head>
<body onload="javascript: abrir()">
<div id="popup">
Esse é um exemplo de popup utilizando DIV. Dessa maneira esse
pop-up não será bloqueado.
<br /><small><a href="javascript: fechar();">[X]</a></small>
</div>
<br /><a href="javascript: abrir();">Abrir POPUP</a>

<br /><a href="javascript: fechar();">Fechar POPUP</a>
</body>
</html>
Explicando a parte lógica: ao clicar no link abrir' dispara a função abrir, que por sua vez muda o display (css, no
caso none) para block, ou seja de não visível para visível, o botão Fechar volta para o display anterior.
No Css position: absolute; Diz que sua posição é absoluta, ou seja, não tem referencia de nenhum objeto top: 30%;
left: 30%; Logo ordena onde vai se posicionado
Versão
Versão Data da Equivalente para Netscape Mozilla Internet Opera Safari Google
publicação Navigator Firefox Explorer Chrome
1.0 March 1996 2.0 3.0
1.1 August 1996 3.0
1.2 June 1997 4.0-4.05
1.3 October 1998 4.06-4.7x 4.0

ECMA-262 1st edition / ECMA-262 2nd edition
1.4 Netscape
Server
1.5 November 2000 6.0 1.0 5.5 (JScript 6.0, 3.0, 1.0
ECMA-262 3rd edition
5.5), 7.0, 3.1,
6 (JScript 5.6), 8.0, 3.2,
7 (JScript 5.7), 9.0, 4.0
8 (JScript 5.8) 10.0
1.6 November 2005 1.5 + Array extras + Array and String generics + 1.5
E4X
1.7 October 2006 1.6 + Pythonic generators + Iterators + let 2.0

JavaScript 70
1.8 June 2008 1.7 + Generator expressions + Expression 3.0

closures
1.8.1 1.8 + Native JSON support + Minor Updates 3.5
1.8.2 1.8.1 + Minor updates 3.6
1.9 1.8.1 + ECMAScript 5 Compliance 4
[1]
[1] John Resig. Versions of JavaScript (http:/ / ejohn. org/ blog/ versions-of-javascript). Ejohn.org. Página visitada em 2009-05-19.
Ver também
• ECMAScript
• Jscript
Ligações externas
• About JavaScript (http://www.mozilla.org/js/) (em inglês)
• Core JavaScript 1.5 Guide (http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide) (em inglês)
• Standard ECMA-262 (http://www.ecma-international.org/publications/standards/Ecma-262.htm) (em inglês)
• Core JavaScript 1.5 Guide:Class-Based vs. Prototype-Based Languages (http://developer.mozilla.org/en/docs/
Core_JavaScript_1.5_Guide:Class-Based_vs._Prototype-Based_Languages) (em inglês)
• Console Interativo (http://cicerocomp.com/jsh/)
71
XML
XML
XML (eXtensible Markup Language) é uma recomendação da W3C
para gerar linguagens de marcação para necessidades especiais.
É um subtipo de SGML (acrônimo de Standard Generalized Markup
Language, ou Linguagem Padronizada de Marcação Genérica) capaz
de descrever diversos tipos de dados. Seu propósito principal é a
facilidade de compartilhamento de informações através da Internet.
Entre linguagens baseadas em XML incluem-se XHTML (formato
para páginas Web), RDF,SDMX ,SMIL, MathML (formato para
expressões matemáticas), NCL, XBRL, XSIL e SVG (formato gráfico
vetorial). A principal característica do XML, de criar uma
infra-estrutura única para diversas linguagens, é que linguagens
desconhecidas e de pouco uso também podem ser definidas sem maior
trabalho e sem necessidade de ser submetidas aos comitês de
padronização.
Características do XML
Em meados da década de 1990, o World Wide Web Consortium (W3C) começou a trabalhar em uma linguagem de
marcação que combinasse a flexibilidade da SGML com a simplicidade da HTML. O princípio do projeto era criar
uma linguagem que pudesse ser lida por software, e integrar-se com as demais linguagens. Sua filosofia seria
incorporada por vários princípios importantes:
• Separação do conteúdo da formatação
• Simplicidade e Legibilidade, tanto para humanos quanto para computadores
• Possibilidade de criação de tags sem limitação
• Criação de arquivos para validação de estrutura (Chamados DTDs)
• Interligação de bancos de dados distintos
• Concentração na estrutura da informação, e não na sua aparência
O XML é um formato para a criação de documentos com dados organizados de forma hierárquica, como se vê,
frequentemente, em documentos de texto formatados, imagens vetoriais ou bancos de dados.
Pela sua portabilidade, já que é um formato que não depende das plataformas de hardware ou de software, um banco
de dados pode, através de uma aplicação, escrever em um arquivo XML, e um outro banco distinto pode ler então
estes mesmos dados.
XML 72
Exemplos
Curriculum Vitae
Codigo XML descrevendo um Currículo:
<?xml version="1.0" encoding="UTF-8"?>

<curriculo>
<InformacaoPessoal>
<DataNascimento>23-07-68</DataNascimento>
<Nomecompleto>...</Nomecompleto>
<Contatos>
<Morada>
<Rua>R.Topazio</Rua>
<Num>111</Num>
<Cidade>Porto</Cidade>
<Pais>Portugal</Pais>
</Morada>
<Telefone>9999-9999</Telefone>
<CorreioEletronico>email@email.com</CorreioEletronico>
</Contatos>
<Nacionalidade>Portuguesa</Nacionalidade>
<Sexo>M</Sexo>
</InformacaoPessoal>
<objetivo>Atuar na area de TI</objetivo>
<Experiencia>
<Cargo>Suporte tecnico</Cargo>
<Empregador>Empresa, Cidade - Estado</Empregador>
</Experiencia>
<Formacao>Superior Completo</Formacao>
</curriculo>
Receita de Pão
Este exemplo demonstra a sintaxe flexível do XML sendo usada para descrever uma receita de pão:
<?xml version="1.0" encoding="ISO-8859-1"?>

<receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">
<titulo>Pão simples</titulo>
<ingredientes>
<ingrediente quantidade="3" unidade="xícaras">Farinha</ingrediente>
<ingrediente quantidade="7" unidade="gramas">Fermento</ingrediente>
<ingrediente quantidade="1.5" unidade="xícaras" estado="morna">Água</ingrediente>
<ingrediente quantidade="1" unidade="colheres de chá">Sal</ingrediente>
</ingredientes>
<instrucoes>
<passo>Misture todos os ingredientes, e dissolva bem.</passo>
<passo>Cubra com um pano e deixe por uma hora em um local morno.</passo>
<passo>Misture novamente, coloque numa bandeja e asse num forno.</passo>
</instrucoes>
XML 73
</receita>
Onde temos na primeira linha:
<Receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">
"Receita" é o nome principal para o seu documento. Note que a semelhança entre XML e HTML é grande, na 1ª
linha abrimos a tag Receita e na última linha a fechamos, como em HTML, assim se estendendo por todo o exemplo.
Vantagens e desvantagens
Com relação aos outros "formatos universais para intercâmbio de dados" já propostos e experimentados, o XML
apresenta diversas vantagens técnicas, mas são as vantagens não-técnicas que o tornam um tópico de tão grande
importância:
• É um padrão "de fato" e formalmente: num universo onde cada desenvolvedor e cada fabricante tem a liberdade
de criar e impor seu próprio formato, a aceitação do XML tem sido vista como o seu maior trunfo. A comunidade
como um todo, ao aceitá-lo, evita o desastre da Babel informática.
• Tem sua origem em uma instituição de padronização das mais abertas e dinâmicas, o W3C.
• Se baseia na experiência de sucesso do SGML, sendo considerado inclusive o "sucessor do SGML".
Vantagens técnicas
• É baseado em texto (TXT).
Com relação aos formatos não-texto (binários), um debate existe desde os tempos do SGML, mas ainda hoje a
comunidade de usuários e desenvolvedores prefere o texto ao binário, e as opções do tipo txt.zip (texto
comprimido) tais como o OpenDocument são a saída mais largamente adotada.
• Suporta Unicode, permitindo que a maior parte da informação codificada em linguagem humana possa ser
comunicada.
• Pode representar as estruturas de dados relevantes da computação: listas, registros, árvores.
• É auto-documentado (DTDs e XML Schemas): o próprio formato descreve a sua estrutura e nomes de campos,
assim como valores válidos.
• A sintaxe restrita e requerimentos de parsing tornam os algoritmos de análise mais eficientes e consistentes.
• É editável, devido à popularidade do XML nos dias de hoje, com diferentes níveis de automação, em qualquer
ambiente:
• Sem automação: editores txt antigos, tais como vi
• Com recurso automático de destaque: a maior parte dos editores txt modernos oferece recursos para destaque
de XML (distinção visual entre tag, atributo e conteúdo).
• Com recursos de visualização e controle (folding) da hierarquia: editores txt mais especializados e editores
simples acoplados a navegadores.
• Com recursos de validação e análise sintática: ferramentas um pouco mais sofisticadas, orientadas a
programadores, tais como as IDEs, ou orientadas a conteúdo, tais como editores XHTML, ambos vem se
adaptando para lidar com outros formatos XML, interpretando DTD, XSLT ou XML Schema.
XML 74
Desvantagens técnicas
As desvantagens em geral se restringem às aplicações que não demandam maior complexidade, tais como vetores,
listas associativas (chave-valor) e informações relativas a configuração, em que o bom-senso estabelece a melhor
escolha (entre o XML ou um formato menos popular).
O "XML simples" pode ser substituído por formatos mais simples, como properties, YAML, JSON e Simple Outline
XML. Os principais critérios para se avaliar a demanda por um formato mais simples são:
• Velocidade: a grande quantidade de informação repetida prejudicando a velocidade de transferência real de
informação (quando esta é transportada na forma de XML).
• Editabilidade txt: o arquivo "XML simples" (como se pode ver nos exemplos acima) pode ser bem pouco
intuitivo, dificultando sua edição com editores txt por pessoas leigas, mais ainda no caso de volume de dados
muito grandes, onde o XML pode sequer ser facilmente editável por pessoas experientes.
O formato properties, por exemplo, é mais fácil de ser editado por leigos, por ser apenas uma lista de itens do tipo
chave-valor, e o JSON é um exemplo de um formato mais prático e rápido em contexto Javascript.
O exemplo abaixo equivale ao exemplo da receita de pão e demonstra como um XML, mesmo sendo sintaticamente
válido, pode ficar de difícil leitura quando criado por ferramentas geradoras de código. A interpretação e a edição de
grandes arquivos XML não indentados são ainda mais complexas para todos,leigos ou experientes:
<?xml version="1.0" encoding="ISO-8859-1"?><receita nome="pão" tempo_de_preparo="5 minuto

tempo_de_cozimento="1 hora"><titulo>Pão simples</titulo><ingredientes><ingrediente quanti
unidade="xícaras">Farinha</ingrediente><ingrediente quantidade="7"
unidade="gramas">Fermento</ingrediente><ingrediente quantidade="1.5"
unidade="xícaras" estado="morna">Água</ingrediente><ingrediente quantidade="1"
unidade="colheres de chá" >Sal</ingrediente></ingredientes><instrucoes><passo>Misture
todos os ingredientes,e dissolva bem.</passo><passo>Cubra com um pano e deixe por uma
hora
em um local morno.</passo><passo>Misture novamente, coloque numa bandeja e asse num
forno.</passo>
</instrucoes></receita>
Regras para boa formação de um arquivo XML

• Todo documento XML, além da tag introdutória, deve ter um único elemento (tag) que sirva como raiz para todos
os demais elementos do documento;
• XML é case sensitive, portanto difere letras maiúsculas e minúsculas, devendo tomar cuidado com o uso de
CamelCases.
• Todo elemento XML deve ser iniciado e fechado, exceto o que define a versão do XML usada e outras definições
de tag única, exemplo <system opera="ligado" onde="aqui" />.
• Comentários em XML são iguais ao HTML () .
XML 75
Ligações externas
• W3C [1] (em inglês)
• W3Schools [2] (em inglês)
Referências
[1] http:/ / www. w3. org/ XML
[2] http:/ / www. w3schools. com/ xml/
Fontes e Editores da Página 76
Fontes e Editores da Página

Java (linguagem de programação) Fonte: http://pt.wikipedia.org/w/index.php?oldid=21406553 Contribuidores: 191228.telemar.net.br, 200.246.143.xxx, 333, Adrianoucam, Alchimista,
Alexanderps, Alexandredinizrodrigues, Bertoche, Bigs, Bihaiko, Bjverde, Braswiki, BrunoSupremo, Carlos-PC, Chico, Cidandrade, Claudomiro Jr, Cícero, Daimore, Daniel Silverio, Dripssouza,
Eduacsp, EduardoCruz, Eduardoferreira, Ematsu, Espardo, Euproprio, FML, Feen, Fernando S. Aldado, Fernando123d, Frhakamine, Gdamasceno, Get It, Girino, Giro720, Gladstone, Hbdbim,
Heldergeovane, I32542, Italo maia, Jcmo, Jonas AGX, Jorge.roberto, JorgeGG, L'AngeRouge, Leonardo.stabile, LeonardoG, LeonardoRob0t, Liclopes, Lijealso, Luckas Blade, Luís Felipe Braga,
Manuel Anastácio, Marcobiscaro2112, Maxtremus, Meira, Mike.lifeguard, Mkasa, Mrcl, Mschlindwein, NH, Nortisop, Nuno Tavares, OS2Warp, Onjacktallcuca, Opraco, Orlando, Osias,
Ozielneto, Paulo Eduardo Azevedo Silveira, PauloColacino, Pedro Henrique Oliveira dos santos, Pepinho, Pietro Roveri, Polonio, Porantim, Rafael.afonso, Raphael csg, Ricardo Caetano de
Moraes, Ricardo Ferreira de Oliveira, Ricvelozo, Roberto Cruz, Rod, Rodrigocansian, Ruy Pugliesi, Samuel.klein, Sandr0G, Tetri, Thevirus, Thiago-manel, Trakinator, Tribal, Tumnus, Vanthorn,
Villarinho, ViniGodoy, Waldir, Waldo Jeffers, Wbrito, Wikifriend pt001, X spager, YuriSanCa, Zuke, 354 edições anónimas
Padrão de projeto de software Fonte: http://pt.wikipedia.org/w/index.php?oldid=21493509 Contribuidores: Bisbis, Brunoslessa, ChristianH, Dobau, Dvulture, FML, FlavioMattos, Francisco
Leandro, Gunnex, Hgfernan, Jorge.roberto, Kleiner, Leofreitas, Leonardo.stabile, LeonardoG, Luís Felipe Braga, Misaelsantos, Morebros, Pablodalloglio, Rafael.afonso, Rui Silva, Villarinho,
ViniGodoy, Wbrito, Yanguas, 38 edições anónimas
Abstract Factory Fonte: http://pt.wikipedia.org/w/index.php?oldid=20276123 Contribuidores: Agil, Comdanilo, Kleiner, Lameiro, Luís Felipe Braga, Reynaldo, 10 edições anónimas
Builder Fonte: http://pt.wikipedia.org/w/index.php?oldid=17468653 Contribuidores: Kleiner, Luís Felipe Braga, 7 edições anónimas
Factory Method Fonte: http://pt.wikipedia.org/w/index.php?oldid=19219965 Contribuidores: Comdanilo, Epinheiro, Gunnex, Kleiner, Luís Felipe Braga, 14 edições anónimas
Prototype Fonte: http://pt.wikipedia.org/w/index.php?oldid=19165305 Contribuidores: Carloskleber, Epinheiro, Kleiner, Luís Felipe Braga, Meirarc, Mr.Yahoo!, Reynaldo, Villarinho,
Waltercruz, 8 edições anónimas
Singleton Fonte: http://pt.wikipedia.org/w/index.php?oldid=21326628 Contribuidores: FML, Fabyo, Kleiner, Leonardo.stabile, Leondil Ribeiro Jr, Luizleao, Luís Felipe Braga, Lépton,
Reynaldo, Xurumelous, 48 edições anónimas
Adapter Fonte: http://pt.wikipedia.org/w/index.php?oldid=20580075 Contribuidores: Adailton, Kleiner, Luís Felipe Braga, Ricardo Caetano de Moraes, Xdeco, 6 edições anónimas
Bridge (padrão de projeto de software) Fonte: http://pt.wikipedia.org/w/index.php?oldid=21492885 Contribuidores: Kleiner, Luís Felipe Braga, Nuno Tavares, Yanguas, 2 edições anónimas
Composite Fonte: http://pt.wikipedia.org/w/index.php?oldid=16797359 Contribuidores: Carlos28, Gfc, Kleiner, LeonardoG, Luís Felipe Braga, 6 edições anónimas
Decorator Fonte: http://pt.wikipedia.org/w/index.php?oldid=20087975 Contribuidores: -
Façade Fonte: http://pt.wikipedia.org/w/index.php?oldid=20472978 Contribuidores: Acfborges, Daimore, Fabiano Tatsch, Joluchetta, Kleiner, Luís Felipe Braga, 9 edições anónimas
Flyweight Fonte: http://pt.wikipedia.org/w/index.php?oldid=20133404 Contribuidores: Bcsanches, Kleiner, Leonardo.stabile, Luís Felipe Braga, 3 edições anónimas
Proxy (padrões de projeto) Fonte: http://pt.wikipedia.org/w/index.php?oldid=20557917 Contribuidores: Belanidia, ChristianH, Tiago de Jesus Neves, 1 edições anónimas
Chain of Responsibility Fonte: http://pt.wikipedia.org/w/index.php?oldid=18127552 Contribuidores: Bathmann, Bisbis, Kleiner, Luís Felipe Braga, Samiboy, Thiago Serra, Waltercruz, 1
edições anónimas
Command Fonte: http://pt.wikipedia.org/w/index.php?oldid=15566439 Contribuidores: Batman, Kleiner, Luís Felipe Braga, Samiboy, Waltercruz, 4 edições anónimas
Interpreter Fonte: http://pt.wikipedia.org/w/index.php?oldid=18025637 Contribuidores: Arges, Batman, Fabiano Tatsch, Girino, Hermógenes Teixeira Pinto Filho, Herschel, Kleiner, Luís
Felipe Braga, 5 edições anónimas
Iterator Fonte: http://pt.wikipedia.org/w/index.php?oldid=16304746 Contribuidores: 555, Arges, Herenvaryar, Kleiner, Leonardo.stabile, LeonardoG, Luís Felipe Braga, 9 edições anónimas
Mediator Fonte: http://pt.wikipedia.org/w/index.php?oldid=20838223 Contribuidores: 555, Batman, Camponez, Carlos Luis M C da Cruz, Chico, ChristianH, Dcolli, Jack Bauer00, Kleiner,
Lucacarvalho371, Luís Felipe Braga, OS2Warp, Usien, 7 edições anónimas
Memento (informática) Fonte: http://pt.wikipedia.org/w/index.php?oldid=21492807 Contribuidores: 555, Alexmoita, Batman, Kleiner, Luís Felipe Braga, Villarinho, Yanguas, 2 edições
anónimas
Observer Fonte: http://pt.wikipedia.org/w/index.php?oldid=20263370 Contribuidores: Arges, Jack Bauer00, Kleiner, Leandromartinez, Luís Felipe Braga, Tiago de Jesus Neves, 8 edições
anónimas
State Fonte: http://pt.wikipedia.org/w/index.php?oldid=15657468 Contribuidores: Categorizador, Kleiner, Potapczuk, Reynaldo, 5 edições anónimas
Strategy Fonte: http://pt.wikipedia.org/w/index.php?oldid=16418852 Contribuidores: Kleiner, Luís Felipe Braga, 1 edições anónimas
Template Method Fonte: http://pt.wikipedia.org/w/index.php?oldid=18139700 Contribuidores: Daimore, FSogumo, JCSJesus, Kleiner, 10 edições anónimas
Visitor Fonte: http://pt.wikipedia.org/w/index.php?oldid=9787399 Contribuidores: Evoluter, Kleiner, Leonardo.stabile, Marco Martins Costa, Mschlindwein, Villarinho, 3 edições anónimas
AJAX (programação) Fonte: http://pt.wikipedia.org/w/index.php?oldid=21232377 Contribuidores: Alchimista, Anderson J de Souza, AnibalSolon, Arcf br, Beto Sis, Brunolmfg, Cassiozen,
Darwinius, Diogocolla, Djio, Dobau, Dpc01, Edneiiamaguti, Eduardoferreira, ElementoX, Epinheiro, Esthonm, Eulinonetto, FML, FSogumo, Felipe Pinto, Fernando S. Aldado, Fábio Soldá,
Gdamasceno, Get It, Giro720, Hyju, Insign, Josenaves, Juntas, Lechatjaune, Leonardo.stabile, LeonardoG, Lijealso, Luis Otávio, Luís Felipe Braga, Marcio68almeida, NGen, Onjacktallcuca,
Phillmelon, Pilha, Poncius, Porantim, Profvalente, Rei-artur, Rhe, Ribafs, Rui Silva, Sam, Seduardo, Slade, Sr X, TXiKi, Thom, Vitorsilva, Xicouto, 256 edições anónimas
JavaScript Fonte: http://pt.wikipedia.org/w/index.php?oldid=21240548 Contribuidores: Agil, AkiraGTR, Alchimista, Alppedroso, Aseditor, AurelioAHeckert, Bardo, Beleza Pura, Bigs,
Camponez, Carlosjordao, ChristianH, Chucky515, Claudio Rogerio Carvalho Filho, Dante, the Wicked, Denesmg, Der kenner, Dpc01, E2mb0t, Eamaral, Edamiani, Eric Duff, Fabiano Tatsch,
Fabiorochafg, Fredxavier, GOE, GRS73, Garavello, Gerbilo, Gunnex, Heldergeovane, HyperBroad, Jic, Jonathan Queiroz, José Roberto A. JR., João Carvalho, LFBossa, Lechatjaune,
Leonardo.stabile, LeonardoG, Leonardob, Lgrave, Lijealso, Luis Dantas, Luís Felipe Braga, Machadoug, Malafaya, Manuel Anastácio, Metzen, Mschlindwein, Nikitta, OS2Warp, One People,
Osias, Pietro Roveri, Polonio, Porantim, Rafael.afonso, Raphael csg, Reynaldo, Ricapita, Ricardo Ferreira de Oliveira, Ricvelozo, Roberto Cruz, Slade, Sygmn, Taliska1, Ts42, Vanthorn, Vini
175, Xandi, Xaves, Yanguas, 178 edições anónimas
XML Fonte: http://pt.wikipedia.org/w/index.php?oldid=21397662 Contribuidores: 333, Adailton, Altenorjr, Antonypeople, Beria, Betty VH, C goulao, Darwinius, Delemon, Diego Queiroz,
Dpc01, Ebalter, EliasAmaral, Gandbranco, Get It, Gtondello, JuloCesarGama, Knee427, Krauss, Leonardo.stabile, Leslie, Lijealso, Lombardi.leo, Lufer, Luís Felipe Braga, Marcelo Reis,
Maurowil, Maurício I, Ninho, Nuno Tavares, Onjacktallcuca, Osias, Porantim, Profvalente, Rfr, Samuel Costa, Scott MacLean, Sr X, Thegoergen, Vigia, Villarinho, Whooligan, 127 edições
anónimas
Fontes, licenças e editores da imagem 77
Fontes, licenças e editores da imagem

Ficheiro:Abstract Factory.gif Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Abstract_Factory.gif Licença: Public Domain Contribuidores: Giacomo Ritucci, Luís Felipe Braga
Ficheiro:Builder UML class diagram.svg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Builder_UML_class_diagram.svg Licença: Public Domain Contribuidores: User:Trashtoy
Ficheiro:Builder (padrão).png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Builder_(padrão).png Licença: Public Domain Contribuidores: Luís Felipe Braga
Ficheiro:Factory Method UML class diagram.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Factory_Method_UML_class_diagram.png Licença: Public Domain
Contribuidores: User:Trashtoy
Ficheiro:Factory Method (portuguese).png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Factory_Method_(portuguese).png Licença: Public Domain Contribuidores: User:Luís
Felipe Braga
Ficheiro:Prototype UML (padrão).png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Prototype_UML_(padrão).png Licença: Public Domain Contribuidores: User:Luís Felipe
Braga
Ficheiro:Prototype sample.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Prototype_sample.png Licença: Public Domain Contribuidores: User:Luís Felipe Braga
Imagem:Singleton.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Singleton.png Licença: GNU Free Documentation License Contribuidores: Bayo, Forseti, Ma-Lik, ManuelGR
Imagem:Adapter.PNG Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Adapter.PNG Licença: Public Domain Contribuidores: Original uploader was Xdeco at pt.wikipedia
Imagem:Bridge.gif Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Bridge.gif Licença: Public Domain Contribuidores: Luís Felipe Braga
Imagem:ElementoGrafico.jpg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:ElementoGrafico.jpg Licença: Public Domain Contribuidores: Gfc
Imagem:Comando.jpg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Comando.jpg Licença: Public Domain Contribuidores: Gfc
Imagem:ClassDiagramTemplateMethod.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:ClassDiagramTemplateMethod.png Licença: GNU Free Documentation License
Contribuidores: Carlos Augusto Matos Coutinho Julio Cesar Soares de Jesus
Ficheiro:XML.svg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:XML.svg Licença: Creative Commons Attribution-Sharealike 2.5 Contribuidores: AutumnSnow, Fryed-peach,
JeffyP, Jusjih, Karl Dickman, Latics, Platonides, SKvalen, Soeb, Verdy p, 3 edições anónimas
Licença 78
Licença
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/

Java XML Ajax Padroes Livro Wikipedia

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Java XML Ajax Padroes Livro Wikipedia

Caricato da

Copyright:

Formati disponibili

Java e Padrões de Projeto

Licenças das páginas

Java (linguagem de programação)

Criado por Sun Microsystems

Estilo de tipagem: estática, forte

Compiladores GCJ, Javac

Influenciada por Objective-C, C++, Smalltalk

Influenciou C#, Fantom, J#, Jython

Principais Características da Linguagem Java

public class OlaMundo {

public static void main(String[] args) {

public abstract class Animal {

public class Cachorro extends Animal {

public class Gato extends Animal {

O exemplo acima cria a classe Animal e duas classes derivadas de Animal.

public interface Pesado {

public interface Colorido {

public class Porco extends Animal implements Pesado, Colorido {

//Implementação da interface Pesado

//Implementação da interface Colorido

//Uma propriedade só do porco

public class Cavalo extends Animal {

private class Parasita extends Animal {

public class MostraBarulho {

//Abaixo um objeto e classe anônimos!

public static void main(String[]args){

//declaração das variáveis

//pede dois números inteiros

//converte os números de string para inteiro

//outra forma de conversão seria utilizar o método valueOf

//efetua a soma dos números

//mostra o resultado da soma para o usuário

//Aqui no exemplo é criado um ArrayList do tipo ArrayList de Aluno, e

ArrayList<Aluno> alunos = new ArrayList<Aluno>();//aqui ha o como aluno

class Auxiliar extends Funcionario {

Padrão de projeto de software

Exemplo de Diagrama em UML para o Padrão Abstract Factory.

abstract class WidgetFactory

public abstract Botao criarBotao();

class MotifWidgetFactory extends WidgetFactory

return new BotaoMotif();

class QtWidgetFactory extends WidgetFactory

abstract class Botao

class BotaoMotif extends Botao

class BotaoQt extends Botao

public class Cliente

Botao botao = factory.criarBotao();

Shared Function obterFactory() As WidgetFactory

Public MustOverride Function criarBotao() As Botao

Public Class MotifWidgetFactory

Public Overrides Function criarBotao() As Botao

Public Class QtWidgetFactory

Public Overrides Function criarBotao() As Botao

Public MustInherit Class Botao

Public MustOverride Sub desenhar()

Public Class BotaoMotif

Public Overrides Sub desenhar()

Public Class BotaoQt

Public Overrides Sub desenhar()

Public Class Client

Dim factory As WidgetFactory = WidgetFactory.obterFactory

Dim botao As Botao = factory.criarBotao

para um construtor de partes do