Padrões de projeto utilizados

Braude (2005) define os padrões de projeto, ou design patterns, como combinações de classes e algoritmos associados a estas que cumprem com propósitos comuns de projeto. Segundo o autor, um padrão de projeto expressa uma idéia em vez de uma combinação fixa de classes. Os algoritmos associados expressam a operação básica do padrão. Metsker (2004) diz que os padrões de projeto estão um nível acima do código e tipicamente mostram como alcançar um objetivo.

Em Gama et al (2000) são apresentados os padrões de projeto catalogados pelos autores, chamados de padrões GOF (Gang of Four). Não interessa para o escopo deste trabalho uma discussão aprofundada sobre todos os padrões (um total de vinte e três) apresentados em Gamma et al (2000). Apresenta-se, portanto, apenas os quatro principais padrões que foram utilizados na modelagem e implementação do Zorelha. Tais padrões são descritos a seguir.

3.3.3.1 Padrão State

O estado de um objeto é uma combinação dos valores atuais dos seus atributos. A lógica que depende desse estado pode espalhar-se por muitos dos métodos da classe. Para evitar este espalhamento pode-se mover o comportamento específico de um estado para dentro de um grupo de classes, com cada classe representando um estado diferente (METSKER, 2004). Para Gamma et al (2000) a intenção do padrão de projeto state é permitir que um objeto altere seu comportamento quando seu estado interno é modificado.

No Zorelha este padrão de projeto foi utilizado para implementar o próprio Zorelha como uma máquina de estados e cada um dos módulos ou atividades como sendo estados desta máquina.

Cada um dos estados é representado por uma classe distinta. A máquina de estados, o Zorelha, também foi modelada como uma classe e possui um método específico para a troca de estados (ver diagrama de classes na Figura 4).

3.3.3.2 Padrão Singleton

Braude (2005) diz que o padrão singleton aplica-se a situações onde é necessário que exista uma e somente uma instância de uma classe em toda a aplicação. Metsker (2004) e Gamma et al (2000) ampliam um pouco mais esta definição dizendo que além de fornecer uma instância única a intenção do padrão singleton é fornecer um ponto global de acesso a esta instância.

Shalloway e Trott (2004) dizem que este padrão funciona através de um método especial utilizado para acessar a instância única do objeto desejado. Ao ser chamado este método confere se o objeto já foi instanciado. Em caso afirmativo o método apenas retorna uma referência para a instância existente. Se a instância ainda não foi criada então o método a cria e retorna a sua referência. Para impedir que outras instâncias do objeto sejam criadas o construtor da classe deve ter acesso protegido ou privado, de maneira que somente a própria classe possa criar instâncias através do método especializado citado anteriormente.

No caso do Zorelha o padrão singleton foi utilizado principalmente para fornecer um ponto de acesso único para as instâncias únicas de algumas classes. No diagrama de classes da Figura 4 pode-se observar algumas das classes marcadas com o estereótipo “singleton”, indicando que a classe é uma instância do padrão de projeto de mesmo nome.

3.3.3.3 Padrão Factory Method

Gamma et al (2000) dizem que um “método fábrica”, um factory method, define uma interface para a criação de um objeto, porém, as subclasses da classe que define o método fábrica é que decidirão qual objeto criar. Metsker (2004) diz que nesse padrão deve-se encontrar uma operação que crie um objeto e que também evite que seu cliente (a classe que invoca o método de criação) saiba qual classe instanciar. Pode-se encontrar diversas classes que implementam a mesma operação de criação retornando o mesmo tipo abstrato, mas internamente instanciando diferentes classes que implementam (no caso da herança de interfaces) ou derivam (no caso da herança de classes) do tipo abstrato retornado.

Figura 3. Classes utilizadas para a seleção de um estado do Zorelha

No Zorelha o padrão factory method foi utilizado principalmente para facilitar a troca de estados da classe Zorelha, a classe que represeta a máquina de estados. Como pode ser observado na Figura 3 a classe base para os botões de seleção de estados – classe BotaoDeSelecaoDeEstado – possui um método abstrato denominado getEstado. Este método é um método fábrica, um factory method, pois a criação dos objetos do tipo Estado não acontece de fato neste método, mas sim na versão do mesmo sobrescrita pelas classes derivadas. Sendo assim, a classe BotaoDeSelecaoDoJogo sobrescreve o método getEstado para retornar uma instância da classe EstadoJogo, enquanto que a classe BotaoDeSelecaoDoShow retorna, na versão sobrescrita do método fábrica, uma instância da classe EstadoShow.

O padrão factory method também foi utilizado para implementar cursores personalizados para os tipos de objetos interativos do Zorelha. Os detalhes são apresentados n seção 0.

3.3.3.4 Padrão Observer

Segundo Metsker (2004) e Gamma et al (2000) o padrão observer define uma dependência de um-para-muitos, de modo que, quando um objeto mudar de estado todos os seus dependentes sejam notificados sobre a mudança. Shalloway e Trott (2004) dizem que o padrão aplica-se a situações onde se tem um conjunto de objetos que precisam ser notificados automaticamente sempre que um evento ocorre.

Um exemplo da utilização do padrão observer no Zorelha é a implementação da alteração da intensidade do som de um instrumento musical. A classe Instrumento implementa a interface IEventDispatcher fornecida pelo Flash, de maneira que as instâncias da classe Instrumento possam

“despachar” ou gerar eventos. Em tempo de execução as instâncias da classe BotaoDeControleDeIntensidade (ver Figura 4) registram-se – através do método addEventListener - como interessadas nos eventos gerados por alguma instância da classe Instrumento. Pode-se dizer que o botão de controle de intensidade observará a intensidade do som do instrumento, sendo que quando esta for alterada o botão será notificado sobre a mudança e poderá executar as ações cabíveis. No caso do Zorelha utilizou-se estas “notificações” para fornecer feedback visual ao aluno sobre a intensidade do som do instrumento. Quando a intensidade do som é alterada para o valor máximo o botão de incremento da intensidade é notificado e então é desativado (os cliques do mouse no botão não são mais processados). Quando a intensidade do som é alterada para o valor mínimo o botão de decremento da intensidade é desativado. Quando a intensidade é alterada para qualquer valor diferente dos valores máximo ou mínimo ambos os botões de alteração de intensidade voltam a processar os cliques do mouse.