 |
| Cliente. |
 |
| Servidor. |
Tópicos de O.O. - Design Fest - Grupo M-2
Diagramas:
UML
Sequencia
Padrões Utilizados:
1. Singleton
O padrão Singleton serve para garantir que uma classe tenha somente uma instância e para fornecer um ponto global de acesso a essa instância. Esse padrão tem como participante único a classe a ser instanciada unicamente (Singleton). Os clientes obtém um objeto da classe Singleton solicitando-o à classe. Por sua vez, a classe Singleton faz o controle do número de instâncias e ao se solicitar uma instância a ela, se já existir uma, a classe retorna essa instância já existente; caso contrário, cria uma instância que será única para todo o sistema.
No sistema proposto, o padrão Singleton é aplicado
em:
• ServidorDePartidas - Como toda Sessão
criada tem de estar visível para todos os controladores de sessão
é imprescindível que haja uma única instância da
classe ServidorDePartidas tendo em vista que é essa classe que é
responsável por "guardar", gerenciar e disponibilizar as sessões.
Observação: Dada a tecnologia escolhida ( JAVA ) é interessante
ressaltar que será necessário um método específico
para a recuperação da instância. Isso é necessário
pois a linguagem não permite o retorno da instância pelo construtor.
Devemos ressaltar também que os construtores da classe devem ser privados
para obter um funcionamento adequado do padrão.
2. Observer
O padrão Observer define uma relação de dependência "um-para-muitos" entre objetos, tal que quando há mudança no estado de um objeto, todos os seus dependentes são notificados e atualizados automaticamente. Esse padrão tem como elementos participantes o Subject, que define uma interface para adicionar/remover dependentes e notificar os dependentes; o ConcreteSubject, que retém o estado de interesse dos objetos ConcreteObserver e notifica esses objetos de sua mudança de estado; o Observer que define uma interface para atualizar os objetos que precisam ser notificados das mudanças no Subject e o ConcreteObserver, que implementa a interface de Observer e precisa atualizar o seu estado conforme o estado do Subject ao qual está associado.
No sistema proposto, o padrão Observer é aplicado
em:
• ControladorDeJogo - É responsabilidade de cada Controlador de
Jogo apresentar graficamente o estado atual do jogo. Para isso, o ControladorDeJogo
atua como observador (ConcreteObserver) sobre a Sessão, sendo notificado
de cada modificação no Estado.
• Sessao - A Sessao por sua vez, atua como o objeto observado (ConcreteSubject)
notificando os objetos dependentes das mudanças no Estado.
• ControladorDeSessoes - O ControladorDeSessoes apresenta ao usuário
todas as sessões disponíveis, para que o Controlador possa apresentar
toda Sessao recentemente criada e deixe de apresentar aquelas que já
terminaram, o controlador atua como observador sobre o ServidorDePartidas, sendo
notificado de toda Sessao que é criada ou terminada.
• ServidorDePartidas - O ServidorDePartidas, assim como a Sessao, atua
como objeto observado tendo como responsabilidade notificar cada ControladorDeSessoes
quando uma sessao e criada ou terminada.
Observação: Tendo em vista as constantes alterações no Estado devido a dinâmica do jogo, é interessante que cada ControladorDeJogo seja notificado uma única vez por ciclo, ou seja, permitir que a LogicaDoJogo atualize cada elemento para então notificar os Controladores.
3. Strategy
O padrão Strategy define uma familia de algoritmos intercambiáveis de forma que estes sejam independentes dos clientes que os utilizam. Esse padrão tem como elementos participantes o Context, que tem seu "comportamento" ou parte dele definido pelo algoritmo implementado pela Strategy referenciada; o Strategy, que define a interface comum para todos os algoritmos; o ConcreteStrategy, que implementa os algoritmos definidos pela interface Strategy.
No sistema proposto, o padrão Strategy é aplicado
em:
• LogicaDoJogo - A LogicaDoJogo determina as regras que estão em
vigor na sessão, ou seja determina a movimentação, colisão
e destruição dos elementos, a quantidade de torpedos suportado
por uma nave, as regras de pontuação e afins. Assim cada LogicaDoJogo,
atuando como uma ConcreteStrategy, define um conjunto de algoritmos que reflete
um modo de jogo para a sessão. Por exemplo, além do modo de jogo
convencional, poderíamos ter um modo de Jogo em equipe, onde um jogador
é penalizado se atingir um companheiro de equipe.
• Sessao - A Sessao atua como Context, tendo a dinâmica de jogo determinada
pelas funções implementadas pela LogicaDoJogo associada.
4. Facade
O padrão Facade fornece uma interface unificada para um conjunto de interfaces em um subsistema. Ele define uma interface de nível mais alto que torna o subsistema mais fácil de ser usado por um cliente. Esse padrão tem como elementos participantes o Facade, que conhece as classes do subsistema às quais deve delegar solicitações dos clientes e, as classes do subsistema, que devem tratar as solicitações transmitidas pelo Facade.
No sistema proposto, o padrão Facade é aplicado
em:
• Gerenciador - A Sessao fornece para o ControladorDeJogo uma interface
de acesso indireto para outras classes como o Estado e a LógicaDeJogo.
5. MVC
O MVC ( Model - View - Controller ) ainda que não exatamente um padrão, é uma arquitetura para GUIs usada com freqüencia. O MVC consiste em dividir a interface ou pelo menos parte dela em três partes de forma que facilitem que o estado de um objeto possa ter varias e possivelmente diferentes apresentações. Essa arquitetura tem como elementos participantes o "model", que gerencia as informações e notifica as "views" quando as informações mudam. Ela contém os dados a serem apresentados e a funcionalidade associada aos mesmos; o "view", que é responsável por mapear os dados de um modelo em uma componente gráfica. A "view" é associada ao "model" e ela apresenta graficamente esse modelo na componente. Além disso, quando o modelo sofre uma modificação, a "view" automaticamente redesenha a apresentação para refletir essas mudanças; o "controller", que é a forma que o usuário interage com o "model".
No sistema proposto, o MVC é aplicado em:
• Sessao - A Sessao é um "model" que contém os
estado de todos os seus elementos. Tais estados são transmitidos para
cada ControladorDeJogo para que este atualize sua respectiva "view".
• ControladorDoJogo - O ControladorDeJogo é o "view" e
o "controller" associado a uma Sessao.
• ServidorDePartidas - O ServidorDePartidas é um "model"
que é responsável por disponibilizar e criar sessões para
um ControladorDeSessoes.
• ControladorDeSessoes - O ControladorDeSessoes é o "view"
e o "controller" associado ao ServidorDePartidas.
|
|
