Padrão de Projeto de Software

Padrões de Projeto

Luiz Carlos da Silveira Júnior ([e-mail])

Pedro Henrique Polonea Paulo Silva ([e-mail])

Vítor Albuquerque Brando ([e-mail])

Departamento de Ciência da Computação - Universidade Federal de Juiz de Fora

Resumo

Basicamente, padrões de projeto (design patterns) são soluções simples para problemas específicos no projeto de software orientado a objetos, são soluções que foram desenvolvidas e aperfeiçoadas ao longo do tempo (GAMMA et al. 1995).

Padrões de projeto ganhou mais popularidade com a obra Design Patterns: Elements of Reusable Object-Oriented Software, onde os padrões propostos no livro são popularmente conhecidos como padrões “GOF”, gangue dos quatro, em referência aos autores Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (OLIVEIRA. 2007).

Segundo (GUERRA. 2013) o livro publicado pelo “GOF” tem mais de 15 anos e de certa forma esta com seu conteúdo ultrapassado. Ainda sim, (GUERRA. 2012) considera este, um livro muito a frente de seu tempo.

Este artigo tem por objetivo apresentar padrões de projeto de software com propostas e modelos do cotidiano conforme os padrões “GOF”, sendo agrupado por padrões do tipo, criação, estruturais e comportamentais, totalizando vinte e três padrões catalogados. Serão considerados conceitos de orientação a objetos, refatoração e reúso, além de breve apresentação sobre o padrão GRASP (General Responsibility Assignment Software Patterns), principalmente sobre MVC (Model-view-controller).

Introdução

(CINNEIDE. 2000) destaca que, desenvolver um projeto certo em uma única vez é praticamente impossível, logo, um dos grandes avanços em software é a concepção de desenvolvimento evolutivo.

Conforme (BLAHA et al. 2006), programação de grandes sistemas refere-se à escrita de programas grandes e complexos com equipes de programadores, onde a comunicação humana torna-se fundamental e isso exige práticas de engenharia de software apropriadas. Para isso, (BLAHA et al. 2006) orienta:

Não programe prematuramente, pense longa e cuidadosamente antes de se comprometer com o código, pois código é cansativo de escrever e difícil de mudar. Crie métodos legíveis, nomes de variáveis significativos aumentam a legibilidade. Mantenha os métodos inteligíveis, desta forma, um método é inteligível se alguém que não é o criador puder entender o código.

Neste cenário, (GUERRA. 2013) afirma que padrões de projeto não são novas soluções, mas soluções que foram implementadas com sucesso de forma recorrente e em diferentes contextos.

Segundo (DANTAS et al.. 2000), um padrão resolve um problema recorrente em um determinado contexto, sendo uma solução que comprovadamente funcione, além de informar os resultados e compromissos de sua aplicação. Por outro lado, um anti-padrão é o resultado da falta de conhecimento de uma solução mais adequada, ou pode ser também, sair de uma solução ruim e chegar a uma boa solução.

Orientação a objetos

Para (BLAHA et al. 2006), o termo orientado a objetos (OO) significa organizar o software como uma coleção de objetos distintos, que incorporam estrutura de dados e comportamentos.

À medida que sistemas de software crescem, também cresce a complexidade associada a eles e torna-se cada vez mais difícil satisfazer a um número cada vez maior de requisitos (FILHO, 2010), assim, programação orientada a objetos serve de elo entre problemas existentes e as soluções computacionais apresentadas no campo da programação.

Refatoração e reúso

Para (CINNEIDE. 2000), refatoração é o processo de mudança de um software de tal maneira que não altere o comportamento do externo do código, contudo, melhora sua estrutura interna.

Refatorar é um modo disciplinado de limpar o código, modificar e simplificar o projeto interno, é capaz de minimizar chances de introduzir erros (RAPELI. 2006).

(RAPELI. 2006) reitera que, tornar sistemas orientados a objetos, mais flexíveis, manuteníveis e com melhor estruturação é utilizar técnicas de refatoração juntamente com padrões de projeto.

Portanto, antes de saber como utilizar os padrões na modelagem inicial, é saber como refatorar um código existente para uma solução que utilize um determinado padrão (GUERRA. 2013).

Já o software reutilizável reduz o custo do projeto, codificação e testes, logo, amortizando o esforço por várias aplicações, simplifica a codificação e portanto, aumenta a probabilidade do código estar correto, (BLAHA et al. 2006).

Segundo (BLAHA et al. 2006), existem dois tipos de reúso, compartilhamento de código recém-escrito em uma aplicação e reúso de código previamente escrito e novas aplicações.

Catálogo de padrões de projeto

Os padrões de projeto variam conforme sua granularidade (partes pequenas) e no seu nível de abstração, como existem diversos padrões, (GAMMA et al. 1995) sugere uma maneira de organizá-los em critérios. Por critério de finalidade ou propósito, onde indica o que o padrão faz e por critério de escopo que especifica se o padrão se aplica a classes ou objetos.

[pic 1]

Ilustração 1. Espaço dos padrões de projeto (GAMMA et al. 2000)

Padrões de criação

Os padrões de criação abstraem o processo de instanciação, ajudam a tornar o sistema independente de como seus objetos são criados, compostos e representados (GAMMA et al. 1995), ou seja, são relacionados a criação dos objetos.

Abstract Factory (kit ou toolkit)

Proposta: Permitir a criação de famílias de objetos inter-relacionados através da utilização de uma classe abstrata.

[pic 2]

Ilustração 2. Abstract Factory (GAMMA et al. 1995)

Builder

Proposta: Separar a construção de um objeto complexo da sua representação, de modo que o mesmo processo de construção possa criar diferentes representações.

[pic 3]

Ilustração 3. Builder (GAMMA et al. 1995)

Factory Method (Virtual constructor)

Proposta: Definir interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar.