Padrões em projetos de software

Recentemente, recebi uma mensagem de um ex-aluno sobre uma questão conceitual de uso de padrões de projeto de software.  A questão era, mais ou menos: membros da equipe de desenvolvimento da empresa onde trabalho querem usar padrões de projeto no desenvolvimento, mas querem alterar os padrões para ajustá-los aos projetos.  A pergunta me fez pensar em um zilhão de ideias que me brotaram na mente, parte  delas eu trouxe para esta postagem, pois certamente podem beneficiar outros interessados no assunto.

Antes de mais nada, padrão é padrão. A definição de dicionário é:
sm (lat patronu) 1 Modelo oficial de pesos e medidas. 2 Modelo. 3 Desenho de estamparia. 4 Título autêntico. P. de cor, Telev: cada um dos três padrões internacionais usados para descrever como as cores da TV e imagens de vídeo são exibidas e transmitidas: NTSC, PAL e SECAM. P. de fato, Inform: um projeto, método ou sistema tão amplamente utilizado que se tornou padrão, apesar de não ter sido reconhecido oficialmente por qualquer comitê. P.-ouro: moeda-ouro. Pl: padrões-ouros e padrões-ouro. (extraido do Dicionário Michaelis-UOL Online da Lingua Portuguesa).

Será que você sairia satisfeito de uma loja, depois de comprar 50 metros de cabo para instalação de rede em sua casa, e o comerciante tivesse medido os 50 metros usando um metro que ele mesmo definiu por conta própria, para ficar mais fácil de medir na concepção dele? Como por exemplo faziam os antigos fenícios, tomando a medida da ponta do nariz até a ponta da mão direita (ou esquerda) com o braço estendido e o nariz “meio” apontando para o lado contrário ao da mão? Testem ai, até que funciona, dá mais ou menos um metro mesmo.

Então, padrões são originados por emergência a partir do uso, observados ao longo de muitas situações que se repetem com regularidade, e medida sua eficiência para aquela situação específica. Depois de propostos são testados exaustivamente, até que sejam aceitos pela comunidade que precisa utilizá-los, e então são adotados como universais e disseminados pelas comunidades. Foi assim com o metro, com o quilograma, com a libra, com o pé, a jarda, com a arquitetura de redes em camadas, padrões de instalação elétrica prediais e residenciais, etc. E é para isso que existem organizações como a ISO (International Organization for Standardization), a ABNT (Associação Brasileira de Normas Técnicas), a ANSI (American National Standards Institute), que cuidam do estudo, definição formal e disseminação de padrões para os mais diversos usos e em todas as áreas tecnológicas.

padroesprojetoOs padrões aplicáveis a  projeto de software disponiveis e disseminados principalmente via o livro Padrões de Projeto do Erich Gamma e colaboradores, aceitos e utilizados por desenvolvedores no mundo todo, não foram (ainda) objeto de uma formalização maior e publicados como uma norma ISO, ANSI ou ABN T. O melhor que se conseguiu fazer foi o catálogo de padrões disponível no livro e em várias outras fontes que surgiram posteriormente, incluidos outros livros. Mas então, já que os padrões de projeto não estão definidos tão formalmente e não estão normatizados, seria razoável adotar um padrão como o Façade por exemplo, e mudar a sua definição para “ajustá-lo” às necessidades que o desenvolvedor considera importantes?

Do ponto de vista de documentação do projeto e de sua manutenção posteriormente, isso seria um desastre, e aumentaria o impacto na documentação, pois estamos falando de um novo padrão que não é o original. Dificultaria muito a manutenção e, se isso for feito com outros padrões no mesmo projeto, com o tempo a rastreabilidade dos requisitos e a manutenibilidade do projeto estariam completamente comprometidos, talvez obrigando a um novo desenvolvimento para restaurar esses atributos importantes do software. E a rastreabilidade é tão importante em projetos, que está presente em todos os modelos de qualidade como um processo de GRE – Gerência de Requisitos (mpsBR, nível G e CMMI, nível 2). Do ponto de vista conceitual, de projeto de software, essa é a questão, e se a necessidade do seu projeto é “quase parecida” com o padrão Façade, o mais correto é não adotar o padrão e você desenvolver a implementação por conta própria, sem citar padrão nenhum.

Claro, se você usa os padrões de projeto corretamente em seus projetos, a discussão sobre como implementar é outra completamente diferente. Implementações podem variar, pois normalmente são atreladas a soluções tecnológicas, sujeitas a muitas escolhas e decisões de implementação.

(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Jersey City, NJ)

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Marcado com: , ,
Publicado em Arquitetura de software, Engenharia de Software, Reflexões
2 comentários em “Padrões em projetos de software
  1. E se observarmos que padrões de projeto são soluções reutilizáveis e elegantes para resolver problemas da orientação a objetos, não vejo para que mudar. Se o problema já foi documentado, catalogado e encontraram uma solução que hoje é aceita por centenas de milhares de pessoas, basta fazer um mapeamento. Tenho X problema, logo tenho a solução Y. O livro do Gamma faz isso muito bem, apresentando o problema para então apresentar a solução. Será que seu aluno não estava falando de outros padrões, como padrões de arquitetura, como MVC, MVP? Pq ai eu mesmo já vi diversas implementações partindo de um mesmo conceito. Mas ai é uma confusão que muitos fazem: Padrão de projeto e padrões de arquitetura. Outro dia vi um aluno meu confundindo refatoração com padrão de projeto.

  2. O mais importante sobre os padrões é que eles são soluções aprovadas. Cada catálogo inclui apenas padrões que foram considerados úteis por diversos desenvolvedores em vários projetos. Os padrões catalogados também são bem definidos; os autores descrevem cada padrão com muito cuidado e em seu próprio contexto, portanto será fácil aplicar o padrão em suas próprias circunstâncias. Eles também formam um vocabulário comum entre os desenvolvedores.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: