20 anos de design patterns

Neste sábado, 15/11/14, tive a oportunidade de assistir a uma palestra com Ralph Johnson no Centro de Competência em Software Livre da USP (CCSL). O Ralph eh um dos Gang of Four, os autores do clássico livro sobre Design Patterns [1] publicado em 1994, um dos livros mais conhecidos da história da programação.

Design patterns (ou padrões de projetos) são soluções para o design de sistemas orientados a objetos que se aplicam em diferentes sistemas. Mas não é simplesmente uma solução reutilizável como uma biblioteca, mas sim um tipo de estratégia que você deve aplicar em suas próprias classes e objetos.

Na minha perspectiva, o maior benefício do estudo sobre padrões de projeto é um melhor entendimento sobre o que realmente trata a Orientação a Objetos (OO). Muitas pessoas que têm apenas um pequeno contato com a OO podem ficar com a impressão de que a coisa trata-se apenas de modelar os “objetos do mundo real” em duas classes de domínio. E muito material por aí acaba reforçando essa visão.

Bom, sobre a palestra...

Considerando os 20 anos que já se passaram desde a publicação do livro, a ideia do Ralph era tentar expor algumas coisas que mudaram desde então e coisas que eles já podiam ter dito desde o começo. Ou então dizer melhor certas coisas que acabaram sendo mal interpretadas. Em muitos slides podia se ver “What the book did not say...”.

Sobre a má interpretação que algumas pessoas fizeram do livro, uma coisa que ele disse se aplica muito ao pessoal acadêmico que escreve artigos (ou na verdade qualquer tipo de texto, ou até mesmo código!): se uma pessoal interpreta mal nosso texto, podemos culpa a pessoa, mas quando muitas pessoas interpretam errado o texto, é preciso que o autor admita parte da culpa.

E um exemplo de má interpretação sobre o livro foi de um cara que assim que aprendeu sobre os padrões simplesmente transformou todas suas variáveis globais em singletons e achou que a coisa então estava bonita. Já no fim do palestra, o Ralph retomou em um slide “Conformity to patterns is not measure of goodness”.

Vou citar agora alguns momentos que achei interessante na palestra.

Uma das coisas que ficou faltando no livro foi abordar a refatoração. Muitas vezes os padrões de projeto podem reforçar a visão de que as classes de um sistema devem ser cuidadosamente projetadas antes de serem implementadas, paradigma que vem perdendo força com os princípios ágeis de refatoração e de design emergente. Mas a verdade é que os Gang of Four já tinham opiniões muito fortes e favoráveis à refatoração já em 1994! A decisão de não comentar sobre isso no livro foi uma questão política, já que os acadêmicos da época ainda eram fortemente apoiadores do antigo paradigma de planejamento mais forte. Para se ter uma ideia do contexto, a primeira edição do livro sobre XP do Kent Beck [2] e o livro sobre refatoração do Martin Fowller [3] ainda estavam para nascer. Para fechar o assunto refatoração: em seu livro sobre design patterns [4], Eduardo Guerra procura apresentar vários padrões no contexto em que são implementados em um sistema já existente por meio de refatorações.

Por falar em outros livros sobre design patterns... o Ralph elogiou o livro sobre design patterns da coleção Head First [5]. Embora com todos os seus desenhos e piadinhas ele pareça um livro “for dummies”, na verdade ele é bem competente em apresentar os padrões e os relacionarem a princípios mais abstratos e fundamentais da orientação a objeto. Outro livro muito elogiado pelo Ralph foi o Domain Driven Design [6].

Uma espécie de crítica a alguns (muitos?) acadêmicos da computação: o pessoal é muito apressado em querer formular teorias sobre coisas com as quais ainda não temos nem prática. Vejam, todos os membros da Gang of Four eram doutores e mesmo assim o livro Design Patterns é extremamente sobre a prática, pois os autores entendiam que antes era preciso falar sobre os padrões para depois se formular teorias sobre padrões. E isso justifica até algumas coisas que ficaram fora do livro, como a noção de que alguns padrões são composto por outros padrões.

Curiosidade sobre linguagens: o livro foi escrito principalmente com exemplos em C++ e com Smaltalk, sendo Smaltalk a linguagem preferida dos autores do livro. Depois de usar Smaltalk, o Ralph chegou a programar bastante em Groovy, que é uma linguagem muito similar a Java, mas que possibilita a utilização de fechamentos (closures).

Em certo momento (numa discussão sobre streams) houve bastante destaque sobre programação reativa. Para aprender sobre o que se trata essa tal programação reativa (eu não sei!), o Ralph indicou uma palestra disponível no Youtube [7].

Agora alguns pontos específico das discussões levantadas sobre alguns padrões do livro.

Singleton. Muita gente critique o singleton. Sobre isso o Ralph disse que concorda que em certos casos há mesmo forças que fazem com que ele não seja uma boa ideia, mas o problema é que as pessoas possuem opiniões muito fortes sobre isso às vezes, não entendendo que uma solução que não é boa em seu contexto, pode ser boa em outro contexto. Mais ainda, o Ralph deu uma sugestão sobre o real problema trazido pelo singleton que não é percebido por seus críticos: a questão é que o singleton encapsula uma parte do estado global da aplicação, o que complica alguns cenários de teste.

Observer. Poderia ser descrito de forma mais similar ao vemos hoje na prática com os listeners e eventos na linguagem Java. E o Ralph admitiu que o livro estava errado quando disse que o modelo no qual os observados enviam os detalhes da mudança de estado para os observadores fazem com os eventos sejam menos utilizáveis, uma vez que o observado tem que saber sobre as necessidades do observador (há um forte acoplamento entre observado e observador). Mas o que acontece na prática hoje é que para cada aspecto de mudança podem haver interfaces observadoras diferentes e até mesmo vários métodos de atualização em uma interface observadora. Isso faz com que a definição do o que é observado seja bem coesa, possibilitando o projeto de eventos bem definidos e reaproveitáveis. Aliás, um detalhe importante é que quando o livro foi escrito, ainda não se utilizava interfaces, conceito difundido com a linguagem Java e que auxilia muito na descrição dos padrões.

Iterator. A grande coisa que ficou faltando é perceber que os iteradores também são aplicáveis a fluxos de dados (streams), uma vez que os fluxos se comportam como arrays, apenas com a diferença de que streams existem sobre o tempo, enquanto que arrays existem sobre o espaço. E o outro ponto é que operações funcionais como o map, filter e reduce do Python podem ser aplicados sobre iteradores.

Para terminarmos refletindo sobre a continuidade do estudo sobre padrões, vou citar a contribuição do colega Luciano Ramalho na discussão final com a plateia: embora os padrões sejam independente de linguagem, como o Ralph destacou no começo da palestra, isso não significa que todos os padrões se aplicam a todas as linguagens. Em um grupo coordenado pelo Luciano Ramalho no Garoa Hacker Clube, já tive a oportunidade de discutir como alguns padrões passam por alterações significativas no contexto de linguagens dinâmicas como Python. Assim podemos dizer que mesmo depois de 20 anos, muita coisa ainda pode ser dita e discutida sobre design patterns.
 

[1] Erich Gamma Page, Richard Helm, Ralph Johnson e John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. 1994
[2] Kent Beck, Martin Fowler. Planning Extreme Programming. 2000
[3] Martin Fowler. Refactoring: Improving the Design of Existing Code. 1999
[4] Eduardo Guerra. Design Patterns com Java: Projeto orientado a objetos guiado por padrões. 2013
[5] Eric Freeman, Bert Bates, Kathy Sierra, Elisabeth Robson. Head First Design Patterns. 2004
[6] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software. 2003
[7] Netflix JavaScript Talks - Async JavaScript with Reactive Extensions. 2014

PS: Aproveitei a oportunidade para pegar um autógrafo do Ralph no livro da biblioteca da minha empresa : )

 

No comments available.

Add new comment