PADRÕES DE PROJETO: DESIGN PATTERNS
Jaime William Dias1, Danilo Venturini1, William Macxuel Muniz1,
Rodrigo Niehues Chagas1
1
Universidade Paranaense (UNIPAR)
Paranavaí – PR – Brasil
[email protected], [email protected],
[email protected], [email protected]
Resumo. Este artigo constitui uma descrição dos padrões de projeto
também conhecidos como design patterns que são utilizados no
desenvolvimento de softwares, tendo como objetivo principal contar um
pouco da história de seu surgimento, as vantagens de seu uso, os
elementos que o compõem, como são classificados e também o que
esperar do uso de um padrão de projeto, para finalizar faremos um
pequeno estudo de caso para melhor externar o assunto.
.
1. Introdução
Sistemas de software têm desempenhado um papel cada vez mais preponderante no
dia-a-dia das pessoas e, consequentemente, se tornaram maiores e mais complexos.
A partir do momento em que os produtos de software se tornaram complexos e que
as atividades do processo de desenvolvimento deixaram de ser atribuídas a uma
única pessoa, passando a ser executada por uma equipe, surgiram medidas que se
tornaram essenciais nesse processo. A padronização de projetos é uma dessas
medidas, o grande desafio das equipes de desenvolvimento de sistemas de software
é produzir sistemas seguros, eficientes, de fácil manutenção, reutilizáveis e em
prazos cada vez menores.
Os padrões de projeto servem para identificar nomear e abstrair estruturas
recorrentes que são utilizadas no desenvolvimento de software tornando dessa
forma a reutilização de códigos muito mais organizada e produtiva. O presente
trabalho traz uma breve descrição sobre estes padrões bem como um pequeno
estudo de caso para exemplificar um desses modelos de projeto [SILVA, P. et al
2009].
2. Metodologia
Para este trabalho foi realizada uma extensa revisão bibliográfica em livros, artigos
e sites da internet. O próximo passo foi organizar as informações e definir os
tópicos, após isto foi iniciada a escrita do trabalho.
3. Padrões
A ideia de padrões de projeto foi apresentada por Christopher Alexander em 1977,
ideia esta que esta ligada a padrões de projeto arquitetônicos, Christopher disse:
“Cada Padrão descreve um problema que ocorre repetidamente de novo e de novo
em nosso ambiente, e então descreve a parte central da solução para aquele
problema de uma forma que você pode usar esta solução um milhão de vezes, sem
nunca implementa-la duas vezes da mesma forma” [KON, Fábio 2014].
Esse conceito ficou adormecido até os anos 80 quando começaram a ser
organizados workshops sobre especificações de projeto e programação orientada a
objeto [JÚNIOR, Nelson Ribeiro de Carvalho 2013], mas foi somente no ano de
1995 que o desenvolvimento de software passou a ter um catalogo de soluções
padronizadas para projetos, que foi o livro Gof. O padrão transmite o conhecimento
de uma pessoa com muita experiência em um determinado assunto, de uma maneira
que pessoas com menor experiência e que se deparam com problemas semelhantes
possam aplica-los [KON, Fábio 2014].
3.1 Vantagens
Com o inicio das catalogações de padrões de desenvolvimento que também são
conhecidos com design patterns surgiram inúmeras vantagens para quem
desenvolve e faz uso desses padrões, vantagens tais como: passou-se a ter um
vocabulário comum para conversar sobre projetos de software, soluções que antes
eram desconhecidas e antes não possuíam um nome, passaram a ter, padronização
de nomenclaturas e desenvolvimentos em camadas, código mais enxuto, limpo,
organizado, aumento da qualidade e diminuição da complexidade do código, entre
tantos outros [KON, Fábio 2014].
3.2 Elementos de um padrão
Em geral, um padrão tem quatro elementos essenciais:
1. O nome do padrão é uma referência usada para descrever um problema de
projeto, suas soluções e consequências. Dar um nome permite ao desenvolvedor
programar em um nível mais alto de abstração, e ter um vocabulário comum
para se discutir com a equipe de desenvolvimento. Sendo assim quando existir
um problema será mais fácil identificar qual padrão usar naquela situação.
[GAMMA, E. et al 2000].
2. O problema fala em qual situação aplicar o padrão, ele descreve o problema e
seu contexto. Algumas vezes o problema trará uma lista de condições que
devem ser satisfeitas para que o padrão seja aplicado [GAMMA, E. et al 2000].
3. A solução descreve os elementos que compõe o padrão de projeto, seus
relacionamentos e suas responsabilidades. A solução não descreve um projeto
concreto ou uma implementação ela apenas mostra um caminho que pode ser
usado, e um exemplo de seu uso [GAMMA, E. et al 2000].
4. As consequências são os fatores que devem ser levados em conta para
utilização ou não do padrão para solução de determinado problema, embora em
projetos de software as consequências geralmente não sejam documentadas, é
importante se analisar se aquela realmente é a melhor solução, se o software
perdera desempenho ou ficara inflexível, tudo isso deve ser levado em conta na
hora de se aplicar um padrão [GAMMA, E. et al 2000].
Os padrões variam em suas formas de uso em sua grandeza e também em seu
nível de abstração. Lembrando que a construção de um software é feita da união de
vários desses padrões que juntos formam a solução para determinado problema.
4. Classificação dos padrões
A dois critérios para se classificar os padrões de projeto o primeiro seria a sua
finalidade que reflete o que o padrão realmente faz, afinal o padrão pode tratar da
parte estrutural ou da criação ou talvez do comportamento de um software por isso
são divididos dessa forma, a tabela 1 mostra uma dessas divisões [GAMMA, E. et
al 2000].
Tabela 1 Espaço dos Padrões de Projeto
Fonte: Padrões de Projeto ; soluções reutilizáveis de software orientado a objetos (2000, p.27).
O segundo critério, chamado de escopo especifica se o padrão se aplica a classe
ou a objetos. Os padrões relacionados à classe lidam com a ligação entre as classes
e suas subclasses, já os padrões relacionados a objetos lidam com relacionamentos
entre objetos e seus relacionamentos entre objetos que podem ser mudados
dinamicamente [GAMMA, E. et al 2000].
4.1 Como selecionar um padrão de projeto
Primeiramente é necessário analisar o tamanho do seu projeto. Depois é preciso
encontrar um padrão que tenha a intenção ou a solução que trabalhe na mesma linha
de seu projeto, depois de selecionado é preciso observar com quais outros padrões
esse padrão escolhido se relaciona, é preciso também procurar padrões semelhantes
ou parecidos com o escolhido e por fim liste possíveis variações e reformulações que
poderão ocorrer durante o desenvolvimento do projeto [GAMMA, E. et al 2000].
4.2 Como usar um padrão de projeto
Uma vez escolhido o padrão de projeto é preciso se utilizar de alguns passos para que
o entendimento e também a aplicação do padrão sejam efetivados de forma correta.
Leia o padrão por inteiro pelo menos uma vez, para que você possa ter uma
visão geral, reforce a atenção em elementos do padrão como o problema e a solução,
olhe nos exemplos de código que o padrão traz para que você possa ter uma ideia
concreta da sua aplicabilidade, escolha nomes que de classes que sugerem quais
padrões ali estão sendo utilizados e por fim defina suas classes seus relacionamentos,
heranças e outros mais [GAMMA, E. et al 2000].
4.3 O que esperar do uso de padrões de projeto
Muitos dos desenvolvedores em geral só ouviram falar dos padrões de projeto mais
em geral nunca os aplicaram de maneira efetiva, mesmo assim se você tem uma
maneira padrão de desenvolver sistemas já esta aplicando uma padronização, o que é
importante é ter ciência de que eles existem e que é preciso estudar esses padrões
para poder produzir softwares de maior qualidade [GAMMA, E. et al 2000].
Hoje fala se muito em software flexível, mas para que essa ideia realmente seja
efetiva e eficaz é preciso firmemente seguir uma padronização de desenvolvimento
para que em um futuro do ciclo de vida de seu software ele não fique engessado
devido a uma má estrutura feita no inicio do projeto, desta forma seguindo padrões
de desenvolvimento teremos um código mais limpo e mais reutilizável [GAMMA, E.
et al 2000].
5.
ESTUDO DE CASO
A seguir mostraremos o uso de dois padrões de projeto, onde na primeira parte o
código é desenvolvido sem a utilização de um padrão, e na segunda parte com a
utilização de um padrão.
Design Pattern Factory
Exemplo de conexão sem utilizar Factory demonstrado na figura 2:
Figura 1 – Código da classe exemplo sem Factory
Agora exemplo de conexão utilizando o Design Pattern Factory. Primeiramente é
criada a classe responsável por fazer a conexão com o banco de dados, como
demonstrado na figura 3:
Figura 2 - Código da classe fábrica de conexão
Depois de criado a classe de conexão, é chamada a classe com o método de criar a
conexão, dessa maneira deixa o código mais limpo e separa a classe responsável pela
conexão, quando precisar da conexão com o banco de dados é só chamar a classe
responsável e criar a conexão, sem duplicar código como mostra a figura 4:
Figura 3 - Código da classe factory
6. Considerações finais
Padrões de projeto foram criados para auxiliar uma parte repetida de um determinado
projeto de software, permitindo desta forma seu entendimento e aplicação em um
contexto particular. Sendo assim eles oferecem aos desenvolvedores uma ferramenta
comum, facilitando a comunicação e o crescimento do projeto em uma linguagem
comum para que todos possam desenvolver seguindo as métricas traçadas no início,
além disso, constroem uma base solida para o desenvolvimento de um software que
seja flexível e que possa ser usado como plataforma para outros sem que cresça tanto
que fique engessado e tenha que ser desenvolvido novamente, esse que é um dos
grandes desafios da engenharia de software e que com a utilização de padrões e
códigos bem escritos espera se resolver boa parte desse problema e diminuir o tempo
de construção de um projeto sem que haja percas neste processo [JÚNIOR, Nelson
Ribeiro de Carvalho 2013].
REFERÊNCIAS
GAMMA, E.; Helm, R.; Johnson, R.; Vlissides, J (2000). “Padrões de Projeto:
soluções reutilizáveis de software orientado a objetos”, Porto Alegre: Bookman,
2000.
JÚNIOR, Nelson Ribeiro de Carvalho (2013). Padrões de projeto e frameworks no
desenvolvimento de software. Disponível em :
<http://revistapensar.com.br/tecnologia/pasta_upload/artigos/a28.pdf/ >. Acesso em
18 de abril, 2014.
KON, Fabio (2014). Padrões de projeto de software orientado a objetos.
Disponível em : <www.ime.usp.br/~kon/MAC5714/aulas/slides/GoF.ppt/>. Acesso
em 19 de maio, 2014.
SILVA, P. et.al (2009). Estudo do Padrão de Projeto Observer no
Desenvolvimento de Softwares Utilizando a Arquitetura MVC, Disponível em: <
www.biblioteca.ifc-camboriu.edu.br/criacac/tiki-download_file.php?/> Acesso em:
25 de agosto, 2014.