Design Patterns na prática – Parte 1- .Net Magazine 76

Este artigo inicia uma série sobre uma área nobre da programação orientada a objetos, a utilização de Padrões de Projeto, ou Design Patterns. Nesta primeira parte, conheceremos o padrão Observer. Aprenda como integrar as partes do seu sistema de maneira sofisticada. Através do uso das interfaces, o Padrão Observer permite que partes distintas se comuniquem sem que uma parte precise conhecer a outra.

Sistemas modernos precisam deixar o usuário informado sobre as mudanças que ocorrem em seu ambiente em tempo real. É isto que se espera de um sistema que se diga integrado. Um bom exemplo para isto é um sistema que possua controle de estoque. Normalmente estes sistemas possuem um algoritmo para fazer o balanço do estoque da empresa. Quando o balanço é iniciado muitas funções do sistema ligadas ao movimento de estoque devem ficar indisponíveis até que o balanço termine. Muitas vezes este controle não é feito e fica sendo responsabilidade do usuário cuidar para que nenhuma venda ocorra durante o processo de balanço. Neste artigo você vai aprender o que fazer para que as partes do seu sistema interajam entre si de maneira elegante, através do padrão Observer.

O desenvolvimento orientado a objetos surgiu para suprir as falhas encontradas no modelo estruturado, porém se seus conceitos forem aplicados de forma impensada, as consequências podem ser piores. Para evitar que esses erros sejam cometidos, um estudo baseado nas ideias de Christopher Alexander resultou nos padrões de projeto, um conjunto de soluções para problemas recorrentes. Implementadas para o modelo orientado a objetos e que constituem boa prática para o mesmo, mostram como preparar um modelo pronto para eventuais alterações. Um trabalho realizado pela GOF (Gang of Four), gangue dos quatro, classificou alguns padrões, impulsionou e difundiu o uso dos mesmos, mas os padrões não se resumem aos classificados pela GOF, existem vários padrões criados para resolver os mais diversos problemas. Contudo, o uso indiscriminado de padrões pode levar a outros problemas, chamados de antipadrões.

Os padrões de projeto existem nas mais diversas áreas, são soluções que foram encontradas para problemas recorrentes. Mas não são qualquer solução. São soluções que foram testadas e testadas e que pela experiência de outros que se utilizaram deles, têm sua funcionalidade comprovada. Os padrões para software não fogem dessa característica, porém, foram adaptados para obtenção de modelos com maior qualidade e flexibilidade. Utilizados em conjunto à orientação a objetos, formam o “par perfeito”. O tema Padrões de Projeto nos últimos anos tem sido considerado como tópico avançado na análise orientada a objetos, porque explora os conceitos base da orientação a objetos de uma forma diferente, apresentando uma nova perspectiva (Shalloway e Troot, 2001).

O Padrão Observer

O padrão Observer garante que as partes específicas de um sistema sejam notificadas de mudanças que acontecem em alguma área do sistema, porém, sem que estas duas partes saibam muito uma da outra, ou seja, a tela de vendas pouco ou nada saberia a respeito do objeto Produtos, mas de alguma maneira seria informada quando o objeto Produtos iniciar a rotina de balanço de estoque.

Imaginando o cenário proposto no quadro Resumo do DevMan, uma das soluções para que o módulo de vendas fique ciente de que o processo de balanço está ativo, é implementar uma verificação pelo uso do componente Timer (no caso de uma aplicação Windows Forms), onde em um período estabelecido, o sistema verificaria se o balanço está sendo feito. Apesar desta ser uma solução comum, não é a mais indicada visto que um número excessivo de solicitações estarão acontecendo desnecessariamente, além do fato de que existe um intervalo de tempo entre uma solicitação e outra. Imagine a seguinte situação:

• O usuário Marcos abre o formulário de venda;
• A usuária Jaqueline, abre a janela de balanço, mas ainda não o inicia;
• O Timer, no computador do Marcos, faz uma verificação para garantir que nenhum balanço foi iniciado;
• Jaqueline inicia o balanço;
• Marcos, salva a venda, o que não devia ser permitido porque a Jaqueline iniciou o balanço;
• O Timer, no computador do Marcos, faz a verificação novamente e agora como o balanço foi iniciado, desabilita o uso da venda para o Marcos, porém, faz isto tarde demais, pois Marcos já fez uma venda quando existia um balanço em andamento.

Neste simples exemplo você pode ver como é frágil um sistema cujas partes são integradas usando um Timer. Você pode diminuir a possibilidade disso acontecer diminuindo o intervalo de tempo, mas isto traz outra consequência: com o uso excessivo de Timers você faz seu sistema parecer mais lento, já que um processamento extra é executado a cada X milissegundos. Pense no Timer como um objeto “burro”, pois ele não sabe quando a informação mudou e faz verificações repetidas vezes mesmo que nada tenha mudado. Pior do que usar Timer para integrar as partes do sistema é não integrar o sistema.

Integrar as partes do sistema não é uma tarefa simples, principalmente quando você tem um sistema que funciona em rede com múltiplos usuários logados ao mesmo tempo. O problema do processo de integração é fazer com que as diversas partes do sistema conversem entre si. Isto é realmente um problema, pois em um mundo orientado a objetos os sistemas devem ser construídos de maneira que uma parte conheça o mínimo ou até mesmo não conheça a outra parte. Então fica a dúvida: como a parte X pode saber se algo mudou na parte Y se o X não pode conhecer o Y? Colocar um Timer seria declarar descaradamente que as duas partes se conhecem, pois a parte com o Timer terá que conhecer os detalhes da parte que será verificada. Felizmente outros programadores já passaram por este problema e documentaram a solução que encontraram. Para esta solução eles deram o nome de Padrão Observer.