Os padrões foram introduzidos por Christopher Alexander no livro “A Pattern Language” onde era especificada uma linguagem que resolvia problemas frequentes na concepção de edifícios. A linguagem criada pelo autor permite a criação de um edifício simplesmente através da aplicação de sequências de padrões. Alexander definiu padrões de arquitectura como uma solução típica para problemas semelhantes, inseridos no mesmo contexto e recorrentes em circunstâncias semelhantes.
De forma análoga, pretende-se que os Padrões de Software resolvam ou ajudem a resolver problemas frequentes que ocorram em circunstâncias semelhantes. Mas, ao contrário dos padrões de arquitectura, a simples aplicação dos padrões de software não resulta por si só na solução do problema. Pretende-se que os padrões de software documentem de forma simples e compreensível as soluções de problemas frequentes no desenvolvimento de software.
4.2 Objectivos
Como já foi dito, os padrões de software têm como objectivo a documentação de soluções para problemas semelhantes que ocorrem frequentemente em circunstâncias semelhantes.
Pretende-se que os padrões de software sejam um meio eficaz de transmissão do conhecimento e experiência dos criadores de software. Assim, os padrões deverão ser documentos escritos com uma linguagem e uma estrutura que sejam comuns e acessíveis por toda a comunidade de criadores de software.
O papel dos padrões no desenvolvimento de software não é apenas resolver problemas. Por estruturarem correctamente as soluções para os diferentes problemas, contribuem para uma boa estruturação dos componentes dos sistemas a desenvolver.
Uma boa estruturação e organização dos componentes do sistema, para além de contribuírem para uma boa e fácil solução dos problemas, contribui ainda para a diminuição das consequências de erros de concepção detectados em estados mais avançados no processo de desenvolvimento do sistema.
4.3 Especificação de Padrões de Software
Atendendo à definição de padrões (solução para problemas semelhantes que ocorrem em circunstâncias semelhantes), podem retirar-se dois dos elementos essenciais que compõem um padrão: a solução e o problema.
Mais dois elementos devem ser considerados: o nome do padrão e as consequências.
• Nome: traduz numa ou mais palavras o problema, a solução e as consequências e é usado para ajudar na abstracção do problema, facilitar a documentação e a comunicação entre os participantes no desenvolvimento do projecto.
• Problema: descreve quando aplicar o padrão. Explica o padrão e o seu contexto, assim como as condições dentro das quais faz sentido aplicar o padrão.
• Solução: descreve os elementos (e relação entre eles) que compõem a resolução adoptada para o padrão. Não descreve a implementação adoptada, mas fornece uma forma onde encaixar a solução.
• Consequências: os resultados a esperar da aplicação do padrão. São muito importantes para a avaliação das alternativas de que se dispõe para resolver um problema.
No livro de referência “Design Patterns” é proposta uma estrutura para documentar os padrões de software que, para além destes quatro elementos essenciais, inclui outros elementos importantes. Os elementos mais relevantes da estrutura proposta é a seguir descrita:
• Nome – deve ser um nome significativo, que traduza bem o que se pretende do padrão, para poder ser usado em qualquer discussão, e de modo a que qualquer pessoa compreenda do que se está a tratar.
• Intuito – descreve o que padrão faz, quais os objectivos e que problemas resolve.
• Motivação – indica as condições quando certo problema ocorre ou quando a solução implementada funciona de acordo com o previsto.
• Aplicabilidade – indica as situações em que o padrão poderá ser aplicado.
• Estrutura – representa graficamente os elementos do problema e da solução e as ligações entre eles.
• Consequências – indica os resultados, vantagens e desvantagens a esperar da aplicação do padrão.
• Implementação – indica pormenores de implementação a que o criador de software que use o padrão deve atender.
4.4 Aplicações - o padrão de software Iterador
Nome – Iterador
Intuito – proporcionar uma forma de acesso a elementos sequencialmente ligados abstraindo a programação de baixo nível.
Motivação – é conveniente permitir a navegação através de variadas estruturas de dados de forma independentemente da organização e pormenores de implementação das estruturas de dados ou objectos.
Aplicabilidade – qualquer entidade que pretenda manipular a informação cuja organização é desconhecida ou de difícil manipulação deverá fazê-lo através de um iterador.
Estrutura – estrutura do iterador na figura 14
14. Padrão Iterador
Consequências – com a aplicação deste padrão, diminui-se a responsabilidade de acesso e navegação, quer da estrutura que agrega os objectos, quer da entidade que pretende aceder aos objectos. Assim, separam-se os algoritmos utilizados na manipulação das estruturas das próprias estruturas.
4.5 Conclusões
Pode-se concluir que os padrões de software são uma excelente forma de comunicação de conhecimentos entre criadores de software. Formalizam, de forma acessível e de fácil utilização, as boas soluções para problemas com que se depara quem desenvolve software.
A identificação de padrões é possível com alguma experiência em desenvolvimento de software. Estes vão tornar problemas de concepção muito mais simples, uma vez que fornecem de forma imediata uma conceptualização do problema e da respectiva solução.
Assim, a passagem para a implementação é quase imediata em programação orientada a objectos.
Caso não se reconheça imediatamente um padrão em determinado problema, a catalogação dos padrões permite encontrar, caso exista, no mínimo, um padrão análogo.
Assim, quem usa padrões terá sempre facilitada a resolução dos problemas que encontra e com o melhor compromisso entre o esforço empreendido e o resultado a esperar.
Para além de ajudarem na conceptualização dos problemas e soluções, os padrões fornecem logo uma organização eficiente entre os componentes de software que, para além de ultrapassar o problema imediato, previne erros em estados mais avançados do desenvolvimento e minimiza as consequências. Deve-se referir, porém, que dos padrões de software resultam soluções comprovadamente boas para problemas comuns e não para problemas específicos em contextos específicos de solução específica.
Pode-se sempre perguntar se há reutilização de software em padrões. De facto, existe pouco ou mesmo nenhum código a reutilizar. Mas o software não deve ser visto apenas como código. O software deve ser visto como um sistema completo com o seu código, as suas estruturas de dados e objectos, os seus algoritmos, os seus componentes e a comunicação entre todos eles. Os padrões podem não fornecer código, nem algoritmos, nem estruturas de dados, mas fornecem indicações sobre alguns dos aspectos mais importantes para o desenvolvimento de qualquer sistema de software.