Padres de Projeto com C# - parte 1

por Jos Augusto de Sousa Barroso

Prefcio
Este material ensina de maneira prtica como escrever aplicaes em C# fazendo uso de
alguns dos mais comuns Design Patterns (Padres de Projeto). Cada demonstrao do uso
dos padres ser ilustrado com diagramas UML para melhor mostrar a interao entre as
classes.
Se voc no possui conhecimento sobre UML, no se preocupe, teremos um breve contato
com os principais diagramas antes de entrar-mos no foco principal deste material, ou seja,
Padres de Projeto em C#.
Como utilizaremos o C#, importante salientar que, neste momento, seria melhor que voc
tivesse conhecimento da sintaxe da linguagem, mas de qualquer forma, estaremos vendo um
pouco de C#
Algo que tambm considerado muito importante neste momento, a Programao Orientada a
Objeto(OOP), mas tambm teremos uma pequena introduo neste assunto.
Basicamente, este um material para quem quer aprender o que so Padres de Projeto e
como utiliz-los em seu trabalho.
Neste material voc vai aprender que Padres de Projeto so maneiras de organizar objetos
em suas aplicaes, de modo a ficar mais fcil codificar e fazer alteraes. Sem falar que,
a medida em que voc for se familiarizando com os Padres de Projeto, estar adquirindo
vocabulrio para melhor discutir sobre como suas aplicaes so construdas.
Estarei descrevendo os padres agrupados em 3 partes: criacional, estrutural e
comportamental.
Sendo assim, estarei dividindo o material em 4 partes:
Parte I: Uma viso geral
Parte II: Padres - Criacional
Parte III: Padres - Estrutural
Parte IV: Padres - Comportamental
Dividindo em partes, estarei facilitando a criao do material, e alm do mais, poderei
disponibilizar as partes assim que as mesmas forem finalizadas, de uma em uma, at que a
ltima parte esteja disponvel tambm.
Por fim, estaremos desenvolvendo aplicaes em C#, e o melhor de tudo, adotando boas
prticas.
O que so Design Patterns?
Primeiramente, Design Patterns a traduo em ingls para Padres de Projeto. Pois bem,
comunmente, no trabalho, nos flagramos em frente a tela do computador pensando: Como
vou escrever esta nova aplicao? Intuitivamente sabemos o que queremos fazer, que tipo
de dados e quais objetos deveremos criar, mas sempre vem aquele recentimentozinho
incomodando de que existe uma maneira mais bacana, mais legvel, ou seja, melhor de se
escrever esta aplicao.
A primeira vista, voc sente que uma soluo bacana seria algo mais reutilizvel e com mais
facilidade para manuteno, e mesmo que a faa, ainda sim estar incomodado com o que fez!
Uma das principais razes que levam os pesquisadores da cincia do computao a
reconhecerem Padres de Projeto a satisfao de se criar algo elegante, porm simples e de
uma soluco bastante reutilizvel.
Padres de Projeto so apenas convenientes maneiras de se reutilizar cdigos orientados a
objeto entre projetos, e tambm, entre programadores.
A idia por trs de Padres de Projeto simples - escrever e catalogar interaes comuns
entre objetos que programadores na maioria das vezes acharam bastante til.
Uns dos padres que mais tem sido citado desde muito tempo atrs o Model-View-Controller
framework para Smaltalk (Krasner e Pope 1988), que divide os problemas que encontramos na
camada de apresentao em 3 partes:
- Model, que contm a parte computacional do programa;
- View, que representa a interface de usurio;
- Controller, que interage com o usurio e a View.
Os Padres de Projetos comearam a serem mais difundidos e reconhecidos por volta de
1990 por Erich Gamma (1992). O auge das discusses e dos encontros tcnicos foi com a
publicao do Design Patterns - Elements of Reusable Software, por Gamma, Helm, Johnson
e Vlissides (1995). Este livro, que normalmente chamado de "Gang of Four", ou "GoF", no
portugus, "gangue dos quatro", teve um forte impacto no que diz respeito a como usar os
Padres e acabou se tornando um bestseller. Este livro descreve os 23 padres mais comuns
e utilizados geralmente, explicando como e quando usar cada um deles. Claro que surgiram
vrias outras publicaes sobre Design Patterns e com diferentes pontos de vista, ou seja,
voltados a Smalltalk, Java, VB e sob o ponto de vista de vrias outras linguagens.
Algumas definies vieram surgindo a partir de ento, sempre vejo o pessoal perguntando,
principalmente em foruns de discusso, como por exemplo o MSDN Brasil, e vejo vrias
respostas.
Mas vamos ver algumas definies mais comuns:
"Design patterns so repetidas solues para problemas de projetos que voc est sempre se
deparando." (Smalltalk)
"Design Patterns constitudo por um conjunto de regras que descreve como fazer certas
tarefas no conceito de desenvolvimento de aplicaes" (Pree 1994)
E por a vai, iremos encontrar vrias outras definies colocadas de uma forma diferente,
mas igualmente corretas. Mas veja bem, na maioria das vezes, quando estamos iniciando
os estudos sobre Padres de Projeto, comeamos a pensar somente nos objetos em si, mas
tambm devemos levar em considerao as interaes entre este objetos. Que possivelmente
pode ser descrito como Padres de Comunicao.
Alguns Padres no tratam somente da comunicao mas tambm das estratgias de
Orientao a Objeto. So estes pontos, ou seja, so estas interaes, o modo de comunicao
entre os objetos, a forma elegante de reutilizao e escrita que tornam os Padres de Projeto
to importantes.
Os padres no param por aqui, existem centenas de literatura sobre eles, muitas definies
e diferentes didticas sobre como aplic-los. Lembro que este material somente uma
introduo aos Padres de Projeto, inclusive sob o ponto de vista do C#, que a linguagem
que vem trabalhando e dedicando meu tempo ultimamente. Neste material, estarei
descrevendo os 23 padres descritos no livro original Design Patterns, e dando foco aos que
considero mais importantes, melhor dizendo, os que so mais utilizados, pelo menos por mim
(risos).
Os autores costumam dividir este padres em trs tipos, farei da mesma forma neste material,
como j mencionei no prefcio, so eles:
- Criacional
- Estrutural
- Comportamental
Detalharei os 23 patterns neste aspecto, inclusive demonstrando cada um deles com a minha
linguagem favorita no .Net, ou seja, o C# , e claro, sem esquecer do UML.
Uma rpida observao:
Se voc realmente deseja "entrar no mundo dos padres", aqui vai um conselho, que a
princpio, no vem de minha pessoa mas j aderi bastante tempo. A primeira coisa aceitar
a premissa de que os Padres de Projeto so importantes no seu trabalho. Ento, voc vai
precisar estud-los detalhadamente e aprender a saber quando deve ser utilizado cada um
deles respectivamente para resolver um determinado problema.
Volto a repetir, este material est muito bom e aps sua leitura voc estar com uma boa base
para poder aplicar alguns dos padres de maneira correta, mas atento, continue estudando,
leia outras livros, entre em foruns especficos, e a propsito, seja sempre bem vindo ao Dot Net
Architect User Group - DNAUG (www.dnaug.com), l voc estar sempre que possvel sendo
informado e at mesmo participando dos encontros e eventos do grupo, ser um prazer t-lo na
comunidade.
Notas sobre Orientao a Objeto
Existem vrias razes para fazer uso dos Padres de Projeto, mas a fundamental razo para
utiliz-los deixar as classes separadas e prevenir delas terem conhecimentos demais entre
elas. Igualmente importante , o uso destes padres no auxlio de voc evitar "reinventar a
roda" e tambm, permitir que voc descreva suas aplicaes de uma forma sucinta, clara e que
facilmente possa ser entendida por outros programadores. Sendo assim, porque no utilizar
UML no mesmo.
Pois bem, existem vrias estratgias que programadores OO usam para fazer esta separao
de classes que mencionei logo acima, entre elas so a herana e o encapsulamento.
Uma classe que herda de uma classe "pai" tem acesso a todos os mtodos desta classe. E
tambm tem acesso a todas as variveis que no so privadas.
Os Padres de Projeto sugerem o seguinte:
- Programe para uma interface e no para uma implementao.
Para deixar isto mais claro, voc deve definir o topo de qualquer hierarquia de classe como
uma classe abstrata ou como uma interface, no qual no implementa nenhum mtodo mas
simplesmente define os mtodos que a classe suporta. Ento, em todas as suas classes
derivadas voc tem mais liberdade de implementar estes mtodos da melhor maneira que
desejar.
Outro conceito importante, Object composition. Ou seja, a construo de objetos que contm
outros. Encapsulamento de vrios objetos dentro de outro. Enquanto muitos dos iniciantes
em OO usam herena para resolver qualquer problema. Quando voc comea a desenvolver
programas mais elaborados, voc ir comear a apreciar os mritos da composio de objetos.
Seu novo objeto pode ter a interface que melhor para o que voc quer fazer, sem ter todos
os mtodos da classe pai. Assim, um outro importante mandamento sugerido pelos Padres de
Projeto :
- D preferncia a Object composition do que a Herana.
Padres de Projeto com C#
Discutirei cada um dos 23 padres. Todos usam classe, interfaces e composio de objetos,
usarei exemplos simples, mas que no deixaro de mostrar a fundamental "elegncia" dos
padres.
Estes padres esto agrupados por categorias como j foi mencionado, pois bem, mas alguns
destes padres so mais ou menos independentes, vou usar um exemplo para melhor explicar
o que quero dizer:
- Usaremos os padres Factory e o Command somente depois de falar-mos sobre eles.
- Usaremos o padro Mediator vrias vezes depois de falar-mos sobre ele.
- Usaremos o Memento novamente quando estivermos utilizando o padro State, o Chain of
Responsability na discusso do padro Interpreter, e o padro Singleton quando estiver-mos
falando do padro Flyweight.
Mas em nenhum caso utilizaremos um padro sem que antes tenhamos falado sobre ele.
- Na medida em que formos exemplificando os padres, veremos vrias caractersticas do C#,
que sero vistos nos padres Adapter e Bridge.
- Veremos outras caractersticas do C# no padro Abstract Factory.
- Enumerao de interface nos padres Iterator e Composite.
- Exceptions no padro Singleton;
- Discutiremos ADO.Net no padro Faade.
- C# Timers no padro Proxy.
Resumindo, cobrirei as principais caractersticas do C# e mostrarei exemplos simples de como
os Padres de Projetos podem nos ajudar a escrever programas melhores.
Neste ponto, aconselhvel que voc tem conhecimento da sintaxe do C#. Facilitaria muito.
Usando Classes e Objetos em C#
Usamos classes para que?
Todo programa em C# composto por classes. Uma classe um conjunto de mtodos
pblicos e privados e dados privados agrupados em unidades lgicas. Normalmente,
escrevemos cada classe em uma arquivo separado, embora no seja a melhor regra. Quando
criamos uma classe, a mesma no uma nica entidade, voc pode criar cpias ou instncias
da mesma, usando o new. Quando criamos estas instncias, passamos dados de inicializao
para a classe usando o constructor. O construtor (constructor) um mtodo que tem o mesmo
nome da classe. No tem nenhum tipo de retorno e pode ter zero ou mais parametros que
passado por cada instncia da classe. Nos referimos como cada uma destas instncias como
objetos.
O que so Namespaces?
Namespaces um jeito de organizar cdigo. Ou seja, eles disponibilizam proteo de conflitos
de nomes, conhecido como namespace collisions. (Coliso de nomes)
Para se criar um namespace, crie um bloco de namespace.
Para mais de uma classe em um mesmo namespace, especifique o mesmo nome de
namespace.
namespace DNAUG
{
class Exemplo
{

}
}
Vejamos alguns exemplos com hierarquia de namespaces em aplicaes WEB:
System.Web
System.Web.SessionState
System.Web.Services
System.Web.UI
System.Web.UI.WebControls
System.Web.UI.HTMLConstrols
System.Web.Caching
System.Web.Mail
System.Web.Security
Todos possuem classes com finalidades especficas. Por exemplo, a System.WebServices
possui classes para criao e utililizao de Web services.
No C#, todos os cdigos esto contidos em classes, se voc quer criar mtodos ou
propriedades que possam ser chamados sem primeiro criar o objeto, declare-os como static
(estticos).
Veja os principais conceitos de OO: Definition (Definio):
Define classes usando o nome
class. Todo o cdigo executvel parte de uma classe.
Access (Acesso):
Existem 5 nveis de acesso a classes e seus membros: public, protected,
internal, protected internal e private.
Inheritance (Herana):
Classes que herdam membros de classes base e override
(sobrescrevem) ou overload (sobrecarregam) membros da classe herdada.
Constructors e Destructors (construtores e destrutores):
Classes possuem constructors e
destructors que so chamados quando um objeto de uma classe criado ou destrudo.
Mtodos construtores possuem o mesmo nome de sua classe e os destrutores so precedidos
por um ~
Abstract classes e Interfaces (Classes abstratas e Interfaces):
Voc pode definir interfaces e
classes abstratas, mtodos e propriedades. Interfaces define os membros e parmetros para
classes que usam a interface. Membros abstratos disponibilizam os itens a serem herdados por
classes derivadas deles.
Nveis de acesso a classes: public:
Todos os membros em todas as classes e projetos.
internal:Todos os membros do atual projeto.
protected:
Todos os membros da classe atual e classes derivadas. Pode ser usado apenas
nas definies dos membros, no para definio de classes.
protected internal:
Todos os membros da classe atual e classes derivadas no projeto atual.
Pode ser usada apenas em definies de membros, no para definio de classes.
private: Disponvel apenas na classe atual.
Pois bem, o foco principal deste material a utilizao de padres de projeto com C#.
Mas como foi dito, existem alguns pr-requisitos para melhor ser a absoro do contedo deste
material.
extremamente necessrio que voc aprofunde seus conhecimentos sobre OOP, o que
descrevi acima, costumo dizer que somente para estigar o leitor e insentiv-lo. Da mesma
maneira com UML. Mas estarei assim mesmo fazendo uma breve descrio sobre cada um dos
diagramas mais utilizados.
OOP est alm do escopo deste material, aconselho um bom estudo sobre o assunto. Porm,
estarei falando um pouco mais. Acredito que seja bastante til e que desta maneira, funcione
como mais um incentivo.
Diagramas UML
Para ilustrar os padres, estaremos utilizando UML. Os diagramas UML foram desenvolvidos
por Grady Booch, James Rumbaugh e Ivar Jacabson.
A UML pode ser utilizada para: Mostrar as fronteiras de um sistema e suas principais funes
utilizando atores e casos de uso.; Ilustrar a realizao de casos de uso com diagramas
de interao; Representar uma estrutura esttica de um sistema utilizando diagramas de
classe, como pode ser observado em um exemplo bem simples anteriormente. Modelar o
comportamento de objetos com diagramas de transio de estado; Revelar a arquitetura
fsica de implementao com diagramas de componente e de implantao; Estender sua
funcionalidade atravs de esteretipos. A UML uma linguagem padro para especificar,
visualizar, documentar, construir artefatos de um sistema e pode ser utilizada com todos
os processos ao longo do ciclo de desenvolvimento e atravs de diferentes tecnologias de
implementao.
Obs.: A UML uma linguagem de modelagem, no uma metodologia.
O modo para descrever os vrios aspectos de modelagem pela UML atravs da notao
definida pelos seus vrios tipos de diagramas. Um diagrama uma apresentao grfica de
uma coleo de elementos de modelo.
Modelar um sistema complexo uma tarefa extensiva sendo necessria a descrio de vrios
aspectos diferentes incluindo o funcional, no funcional e organizacional. Cada viso descrita
em um nmero de diagramas que contm informao enfatizando um aspecto particular do
sistema.
Vejamos os principais diagramas: Diagrama de classe Diagrama de caso de uso Diagramas de
interao Diagrama de sequncia Diagrama de colaborao Diagrama de estado Diagrama de
atividade Diagrama de implementao Diagrama de componente Diagrama de implantao
Vejamos agora alguns exemplos:
Diagrama de classe
Diagrama de caso de uso
Diagrama de sequncia
Diagrama de atividades
Diagrama de estados
Basicamente, utilizando como exemplo um diagrama de classes, o diagrama UML consiste de
caixas que representam as classes.
Considerando uma classe
Veja cdigo:
public class Monstro
{
private string nome;
private int idade;
public Monstro(string nm, int ida)
{
nome = nm;
idade = ida;
}
public string TipoMonstro()
{
return "domado";
}
public int getIdade()
{
return idade;
}
public void separaMonstros() { }
}
Representao da classe em UML:
Exemplo de Herana
Veja cdigo:
public class Monstro
{
private string nome;
private int idade;
public Monstro(string nm, int ida)
{
nome = nm;
idade = ida;
}
public string TipoMonstro()
{
return "domado";
}
public int getIdade()
{
return idade;
}
public void separaMonstros() { }
public abstract string getHabitat(); //para Override
}
Agora, derivamos a classe BichoPapao desta e preenchemos algum cdigo para o mtodo
getHabitat.
public class BichoPapao : Monstro
{
public BichoPapao(string nm, int ida):base(nm, ida) {}
public override string getHabitat()
{
return "Assustador de crianas";
}
}
Representao em UML:
A UML est alm do escopo deste material, aconselho um bom estudo sobre o assunto.
Porm, estarei sempre utilizando-a para podermos visualizar os padres. Acredito que seja
bastante til e que desta maneira, funcione como mais um incentivo.
bastante til e que desta maneira, funcione como mais um incentivo.
A parte I do material termina por aqui, em breve estarei disponibilizando a parte II. Divirta-se!
Para saber mais sobre o autor ou ver outros artigos, visite o DNAUG:
http://www.dnaug.com
Tire a sua dvida na lista de discusso do DNAUG:
http://groups.yahoo.com/group/dnaug/
Fonte:
- MSDN Library
- Padres de Projeto - Solues Reutilizveis de software Orientado a Objetos
- Utilizando UML e Padres
- Design Patterns - Elements of Reusable Software
- Introduction to Design Patterns in C#