Os padrões de projeto vêm sendo amplamente difundidos nas últimas décadas principalmente como um conjunto de técnicas de programação consolidadas para resolver problemas conhecidos no desenvolvimento de software.

Estes conceitos ganharam força a partir de 1995 com a publicação do livro “Design Patterns: Elements of Reusable Object-Oriented Software”, cujos autores ficaram conhecidos popularmente (pelo menos pela comunidade de desenvolvedores e afins) como Gang Of Four, ou simplesmente, GoF.

O que aconteceu com os padrões GoF

Os 23 padrões definidos por GoF vêm sofrendo algumas adaptações com o passar dos anos para atender problemas com contextos diversos e a evolução das próprias linguagens e frameworks. Além disso, conforme a demanda por desenvolvimento vai aumentando, e novos desafios são lançados aos arquitetos e desenvolvedores de software, novas técnicas e algoritmos são implementados.

A maioria, entretanto, acaba não se consolidando como um padrão, seja por serem boas ideias que ainda não foram apresentadas e divulgadas à comunidade, seja por resolverem um problema muito específico, por se utilizar de técnica que contraria princípios básicos da orientação por objetos, ou ainda se caracterizar por solução muito complexa e pouco eficiente (o que pode caracterizar um anti-padrão de projeto).

Outro importante aspecto dos padrões de projeto é a evidente contribuição para os princípios do Desenvolvimento Ágil. Um padrão bem aplicado contribui em diversos fatores, como modularidade, reaproveitamento, legibilidade, e simplicidade do código. Esses fatores ajudam a tornar um sistema menos complexo de ser desenhado, desenvolvido, mantido e evoluído.

E o que o Null Object tem a ver com isso?

Gostaria de citar neste artigo um exemplo de padrão simples, que sequer faz parte dos 23 padrões clássicos de GoF, mas que contribui para um código mais limpo e inteligível. Trata-se do Null Object, muito bem definido no diagrama abaixo:

 

Para entender sua aplicação, basta lembrar daquele objeto que é referenciado em várias partes do seu código e que, por diversas razões, pode estar nulo. Um recurso amplamente utilizado é verificar se o objeto está devidamente instanciado toda vez que for referenciá-lo.

Algumas linguagens oferecem recursos para facilitar um pouco a vida do programador. Por exemplo, o “null conditional operator”, em C# (não conheço algo equivalente em java ou outra linguagem).

Null Object é definido por uma versão padrão de uma classe concreta. No caso do diagrama acima, toda instância de “AbstractObject” deve sempre ser inicializada com “NullObject”. Quando a classe “Client” invoca o método “request”, nenhuma validação prévia é necessária. E ainda, nenhum erro correrá em runtime, mesmo que eventualmente a instância não seja substituída por “RealObject”, que efetivamente executa algum processamento.

Em breve citarei outros padrões importantes, nem sempre tão utilizados que, assim como o Null Object, não só resolvem problemas comuns, mas contribuem para aplicação de qualquer processo de desenvolvimento ágil.