Design Pattern e a Reusabilidade de Software

Klevison Matias

Introdução Tema

O presente trabalho visa abordar os principais conceitos relativos aos Padrões de Projeto de Software, os quais descrevem possíveis soluções de problemas comuns encontrados em projetos orientados a objetos (Meyer, 1997).

Introdução

Com a crescente necessidade de se obter excelência nos serviços e produtos, em toda ou qualquer empresa, surge a necessidade das mesmas obterem uma boa estrutura para se adaptarem às crescentes exigências do mercado. Esse cenário visa encorajar cada vez mais assuntos como produtividade e qualidade. Para a área de software não é diferente. Reutilização é um ponto chave para produtividade, sendo também um dos atributos considerados na avaliação de qualidade de software.~\citep{Pree1995a}.

Introdução

• 1977 Cristopher Alexander - A Pattern Language: Towns, Buildings, Constructions• 1995 Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides - Design Patterns: Elements of Reusable Object-Oriented Software

Introdução

• Padrões resolvem problemas reais, sendo soluções já comprovadas e testadas em diversos casos de um ou vários domínios;• Capturam o conhecimento dos modeladores mais experientes, aumentando o reuso de idéias;• Ajudam modeladores iniciantes a compreender e resolver problemas complexos;• Podem ser utilizados para registrar e encorajar o reuso das melhores práticas;• Capturam partes essenciais do projeto de forma compacta;• Aumentam o nível de abstração para o desenvolvimento de soluções para os problemas;• Formam um vocabulário comum para discussão e resolução de problemas;• Servem para melhorar a comunicação entre membros de uma equipe;• Indicam, além da solução, as condições necessárias para aplicá-la, o raciocínio lógico utilizado para concebê-la, as restrições e custos associados.

Conceitos PreliminaresOrientação a Objetos

Segundo Agostini2007 a modelagem orientada a objetos é um modelo de software e um paradigma de implementação em que o foco principal é sobre as estruturas de dados. Essas estruturas de dados estão divididas basicamente em classes e objetos. Entender sistemas orientado a objetos é a arte de combinar o concreto (objetos e suas interações) com o abstrato (classes e seus relacionamentos) Lange1995.

Durante o tempo de execução, essas classes são instanciadas por objetos que trocam mensagens e realizam as tarefas associadas ao software. Conceitos como herança, composição, polimorfismo, encapsulamento e abstração (que serão vistos mais adiante) dão suporte ao desenvolvimento de estruturas de classe eficientes.

Conceitos PreliminaresReusabilidade de Software

Todo o conceito de orientação a objetos visto acima tange uma das principais propostas do design patterns, a reusabilidade. A orientação a objetos oferece uma gama de soluções para se projetar de maneira reutilizável. A reusabilidade não é obtida pelo simples fato de desenvolvermos softwares orientados a objetos.

O software deve ser planejado para ser reusável. O uso de design patterns é um “acordo”' com o reuso de código, um dos principais princípios da orientação a objetos, que assegura modularidade e extensibilidade para o projeto Agostini2007.

Conceitos como herança e interfaces devem ser encorajados a fim de se obter o máximo de reuso do código, pois como visto anteriormente esses conceitos ajudam a generalizar problemas em um projeto de software.

Segundo GAMMA1995 projetar software orientados a objeto é difícil, mas projetar software reutilizável orientado a objetos é ainda mais complicado. Pois para a utilização de patterns requer experiência do projetista em orientação a objetos, para que o mesmo possa identificar no seu projeto em particular onde os patterns podem ser aplicados.

Conceitos PreliminaresReusabilidade de Software - História

O conceito de reusabilidade teve força a partir do advento da orientação a objetos e tornou-se mais fortalecida com a evolução dos mesmos e a criação de conceitos como \textit{design patterns}. Os softwares de outras gerações costumavam ser acoplados e pouco coesos, tornando a manutenção e a evolução uma tarefa penosa.

Com a evolução desses conceitos os projetistas mais experientes perceberam que determinadas soluções de projeto poderiam ser aplicadas em diferentes casos, logo, eles reusaram essas soluções. Com a ajuda dessas experiências de sucesso, o reuso de software tornou-se algo mais comum entre os projetistas de software.

Conceitos PreliminaresReusabilidade de Software - Objetivo

A reusabilidade pode ser considerada algo que irá prover ``informações ou serviços'' de programas que podem ser usados em múltiplas aplicações, tornando-se resposta importante aos problemas de produtividade de software.\begin{quote} Um dos principais objetivos do desenvolvimento de software orientado a objeto é o de melhorar a reusabilidade de componentes de software. Padrões de projeto devem ajudar a melhorar a reusabilidade. Aumentar a reusabilidade de software é considerada como precondição técnica crucial para melhorar o qualidade geral do software e reduzir os custos de manutenção e produção.~\citep{Pree1995}. \end{quote}

Conceitos PreliminaresReusabilidade de Software - Motivação

A reutilização de software se torna uma barreira para muitos programadores, pois em muitos casos os benefícios são percebidos a longo prazo fazendo com que a equipe fique desmotivada em desenvolver soluções reutilizáveis quando, em geral, a linha de tempo para o desenvolvimento de um software é curta. Existe também a barreira técnica, pois muitos programadores podem não entender o que reusar ou como reusar.

Para se criar um projeto de software (padronizado) onde se justifique o uso das melhores práticas faz-se necessário um conhecimento acurado de orientação a objetos e \textit{design patterns} como também motivação e visão , a longo prazo, da equipe. No que se diz respeito à reutilização e flexibilidade, não existe meio termo. Ou se projeta de uma maneira concisa para que esse software seja adaptável e reutilizável ou não se projeta.

Design Patterns

Após uma abordagem sucinta no que se refere a reusabilidade e orientação a objetos, estamos aptos a desenvolver uma boa abordagem sobre \textit{design patterns}.

Design PatternsIntrodução

Design patterns vem ganhando grande aceitação como uma ferramenta para modelagem orientada a objetos Agostini2007, pois existem problemas de software que, embora estejam situados em contextos diferentes, podem ser solucionados de maneiras semelhantes. Fazendo com que problemas antigos, que foram já foram vivenciados pelos programadores mais experientes, serão catalogados e padronizados para evitar futuros problemas. Para Agostini2007 os patterns são estruturas classe que foram usadas por muitos anos e foram estabelecidos como soluções eficientes para muitos problemas.

Design PatternsOrigem

\textit{Design Patterns}, também conhecidos como padrões de projeto, tiveram origem no conceito de reuso de software. Como já havia sido abordado anteriormente, o conceito de padrões de projeto foi criado no final da década de 70 pelo engenheiro civil Cristopher Alexander. Percebendo que todas as construções de edifícios possuíam algumas características em comum resolveu catalogar estas soluções em seu livro \textit{The Timeless Way of Building}.

Na área de engenharia de software essas práticas foram adaptadas para a construção de sistemas de informação. Liderada por Erich Gamma a \textit{GoF} (\textit{Gang of Four}) - Erich Gamma, Richard Helm, Ralph Johnson a John Vlissides publicaram o livro \textit{Design Patterns: Elements of Reusable Object-Oriented Software}. O livro continha a descrição de 23 padrões para problemas que eram comumente encontrados durante o desenvolvimento de software.

Design PatternsConceito

Um padrão pode ser definido como sendo um esboço, em vez da implementação específica, ou seja, um modelo a ser seguido durante a construção do software (Coad, 1995). As melhores práticas, de projetos antigos, são executadas visando que o esforço para evitar retrabalho seja mínimo. A principal proposta não está no fator tecnológico, mas sim em criar uma cultura na qual a catalogação de experiências e soluções para apoiar toda uma equipe de desenvolvimento de software seja algo importante e motivador. Com essas experiências já testadas e comprovadamente ideais, tem-se um vocabulário comum que permitirá uma melhor comunicação entre a equipe.

Design Patterns são metodologias de construção de software comprovadamente funcionais que garantem legibilidade, manutenabilidade e reutilização de código-fonte no desenvolvimento de alguma aplicação computacional WELFER2005. Para fazer uma analogia sucinta pode-se usar o exemplo dado por Pree1995 “Motoristas aplicam um certo pattern para definir a transmissão manual do veículo em movimento. Este equilíbrio de embreagem e de combustível é aplicado não importando se o veículo for um Fusca ou um Porsche 959”.

Fazendo um pequeno resumo do que foi digo anteriormente sobre design patterns, poderíamos dizer, de forma sucinta, que um design pattern “é uma solução para um problema em um determinado contexto” GAMMA1995, onde:

Contexto se refere ao conjunto de situações, que se repetem, nas quais o design pattern pode ser aplicado; Problema se refere ao conjunto de “forças” (objetivos e limitações) que ocorrem dentro do contexto; Solução é uma estrutura formal para ser aplicada na resolução do problema.

Segundo GAMMA1995 um padrão tem quatro elementos essenciais: O nome do padrão é uma referência que podemos usar para descrever um problema de projeto, suas soluções

e consequências em uma ou duas palavras. O problema descreve em que situação aplicar o padrão; A solução descreve os elementos que compõem o padrão de projeto, seus relacionamentos, suas

responsabilidades e colaborações; As consequências são os resultados e análises das vantagens e desvantagens da aplicação do padrão;

Design PatternsClassificação

Pode se classificar os padrões de projeto de várias maneiras, porém o mais comum é classificá-los de acordo com os tipos de problemas que eles resolvem. De acordo com esse critério, os padrões podem ser:

Criação resolvem os problemas da criação de objetos; Comportamentais que lidam com os problemas de atribuição de responsabilidades aos objetos; Estruturais que lidam com os problemas de relacionamentos entre objetos;

Design PatternsMotivação

Design patterns têm vários usos no processo de desenvolvimento de software orientado a objetos (Schneide, 1999):

Formam um vocabulário comum que permite uma melhor comunicação entre os desenvolvedores, uma documentação mais completa e uma melhor exploração das alternativas de projeto. Reduz a complexidade do sistema através da definição de abstrações que estão acima das classes e instâncias. Um bom conjunto de padrões aumenta muito a qualidade do programa;

Constituem uma base de experiências reutilizáveis para a construção de software. Funcionam como peças na construção de projetos de software mais complexos; podem ser considerados como micro-arquiteturas que contribuem para arquitetura geral do sistema;

Reduzem o tempo de aprendizado de uma determinada biblioteca de classes. Isto é fundamental para o aprendizado dos desenvolvedores novatos;

Quanto mais cedo são usados, menor será o retrabalho em etapas mais avançadas do projeto.

Aplicação PráticaSingleton

O pattern Singleton está entre um dos mais simples patterns a ser implementado, pois seu objetivo é apenas garantir que seja mantida somente instância de um determinado objeto. Ou seja, a própria classe garante que nenhuma outra instância seja criada, bem como oferece uma maneira de acessar sua própria instância.

Uma das finalidades mais utilizadas pelo padrão Singleton é o acesso ao banco de dados de uma determinada aplicação, haja vista que pretendível evitar ao máximo o número conexões abertas em tempo de execução. A classe que utilizará o padrão Singleton para esta finalidade garantirá que somente uma conexão será usada e persistida durante o tempo de execução.

Aplicação PráticaFactory

Existem certas situações em aplicações que, seja por uma intervenção humana ou por uma implementação mais complexa, o programador não saberá como o programa irá se comportar diante de uma determinada situação. Com isso, o programador pode não saber que classe deverá ser instanciada em determinado momento de uma aplicação. Para facilitar esse tipo de situação foi criado o pattern Factory.

Segundo GAMMA1995 o pattern Factory pode ser usado nas seguintes situações:

Uma classe não pode antecipar a classe de objetos que deve ser criada; Uma classe quer que suas subclasses especifiquem os objetos que ela

cria; Classes delegam responsabilidades para uma dentre várias subclasses

auxiliares, e se deseja localizar o conhecimento de qual subclasse auxiliar implementa a delegação.

Aplicação PráticaFaçade

O objetivo deste pattern é fornecer uma interface unificada para um conjunto de interfaces em um subsistema (Gamma et al., 1995). Ou seja, o pattern Façade é o isolamento entre camadas de um sistema, permitindo uma interface mais simples de comunicação entre essas camadas, como também um acoplamento baixo. A figura 2.2, abaixo , demonstra como a interface unificada minimiza a comunicação e as dependências entre os subsistemas que compõem a aplicação.

Referências