PADRÕES DE PROJETO: DESIGN PATTERNS

Jaime William Dias1, Danilo Venturini 1, William Macxuel Muniz 1,

Rodrigo Niehues Chagas1

1Universidade Paranaense (UNIPAR) Paranavaí – PR – Brasil

danilo_tr98@hotmail.com, william.muz@gmail.com, rodrigonchagas@gmail.com, jaime@unipar.br

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:

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

Figura 2 - Código da classe fábrica de conexão

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.