Design Pattern utilizados no Projeto
Design Pattern Composite
A arquitetura do sistema está montada em cima do design pattern Composite.
A concepção do sistema baseou-se em três elementos de grande importância: Sala, Evento e Programação.
Modelou-se a estrutura interna destes elementos da seguinte forma: uma sala possui vários eventos, e este possui várias programações. Dependendo do tipo de evento, este pode possuir uma ou várias programações. Isto é, caso um evento seja não-repetitivo, ele possuirá apenas uma programação, caso seja repetitivo, possuirá várias programações.
O fato de alocar dois elementos consiste em três etapas:
1. ver se o elemento a ser alocado já está alocado
2. ver se um elemento combina com outro (se os atributos de um atende os requisitos de outro, e se os atributos deste atendem os requisitos do primeiro)
3. ver se os elementos dão conflito entre si (se um evento dá choque de horário com outro, por exemplo).
A terceira etapa faz merecer uma melhor elucidação:
Para que um evento dê conflito com outro, faz-se necessário que alguma programação de um evento dê conflito com alguma programação de outro evento. Desta forma, os elementos conflitantes consistem nas programações. Agora em mais alto nível, para que um evento dê conflito com uma sala, faz necessário que algum evento alocado na sala, dê conflito com ele.
Desta forma, temos aqui uma recursão: uma sala dá conflito com um evento, se o evento dá conflito com algum dos eventos alocados na sala, um evento dá conflito com outro evento, se alguma das programações do evento, dá conflito com alguma das programações dele, para que uma programação dê conflito com outra, é preciso que dêem choque de horário.
Inspirado nesta motivação, o design pattern Composite surgiu. Tendo a programação como elemento básico, e o evento e a sala como elementos compostos.
Estes elementos consistem de elementos de alocação. Um elemento desta natureza é Combinável, isto é, para que eles possam ser alocados, os atributos de um atende os requisitos de outro, e o inverso do mesmo jeito.
Desta forma, temos a interface ElementoDeAlocacao que estende a interface Combinavel. ElementoDeAlocacao possui duas implementações abstratas: AbstractElementoDeAlocacao (para elementos simples) e AbstractElementoCompostoDeAlocacao (para elementos compostos).
A interface Combinavel possui uma implementação abstrata, que é herdada por AbstractElementoDeAlocacao, que por sua vez, é herdada por AbstractElementoCompostoDeAlocacao. Esta última sobrescreve alguns métodos de sua mãe, para possibilitar que um elemento composto possua vários filhos.
As características dos elementos de alocação são representadas pelas interfaces ConjuntoDeCaracteristicas e Característica. A implementação abstrata de Combinavel prover toda a implementação.
Desta forma, os elementos que desejam fazer parte da estrutura (sala, evento e programacao), deverão apenas implementar a interface ElementoDeAlocacao (relacionamento não exibido na figura, para melhorar a visualização) e estender uma das implementações abstratas desta estrutura, dependendo se for um elemento composto ou simples.
Finalizando, o Composite utilizado neste design foi promovido com o objetivo de facilitar a forma com que a verificação de conflitos é feita (partindo de um todo para suas partes). Além disto, este design oferece uma grande flexibilidade, possibilitando a fácil adição de novas estruturas no sistema.
É claro que o design Composite possibilita criar estruturas sem sentido, como uma sala dentro de outra. Estes relacionamentos são evitados pela camada de script.
Click na figura acima para ver os métodos de cada entidade.
Design Pattern Template Method
O método alocar faz três verificações acima mencionadas. O método que verifica a existência de conflito possuiConflitoCom consiste em um Template Method, uma vez que dependendo do tipo de elemento de alocação, uma implementação diferente será promovida. Desta forma, ele define o esqueleto do algoritmo da operação, postergando a definição de alguns passos para subclasses.
Design Pattern Facade
Cada camada do sistema (script, lógica e persistência) possui uma fachada. Cada uma encapsulando o seu comportamento interno.
Por exemplo:
A classe principal do sistema é o Alocador, ela inicia tudo. Ela instancia objetos que representam a fachada de cada camada. A instância de Alocador só consegue iniciar a camada de apresentação, que só consegue enviar comandos para a camada de script (um único método visível), esta por sua vez, possui uma referência para a fachada da camada de negócios que por sua vez só possui métodos nos quais os parâmetros são Strings, isto é, a camada de script não sabe da existência de nenhum objeto da camada de negócios (tudo encapsulado). Da mesma forma, a camada de negócios só consegue ver um método da camada de persistência, que permite retornar uma hashmap contendo os elementos persistidos.
Desta forma, a complexidade entre as camadas é muito pequena, tudo está encapsulado na camada.
Design Pattern Padrão Command
Permite que todos os comandos da linguagem sejam encapsulados em objetos.
Quando o usuário envia um comando, itera-se todos os comandos passando para cada um o tokenAtual (para verificar se o comando diz respeito ao objeto) e os outros tokens restantes. A idéia é, caso o tokenAtual represente o comando do objeto, este faz uma análise dos tokens restantes verificando se o comando obedece e linguagem e processando o mesmo.
Design Patterns Singleton, Strategy, AbstractFactory e Visitor
Como foi mencionado anteriormente, um evento pode ser repetitivo ou não-repetitivo. Dependendo desta informação, ele teria uma programação ou várias programações.
Desta forma, um Evento possui um GeradorDeProgramacoesIF que encapsula em suas implementações diferentes estratégias de como gerar programações. Foram implementadas duas estratégias: uma de geração de eventos repetitivos e oura de eventos não repetitivos.
A criação de um gerador de programações é feita pela classe GeradorDeProgramacoesFactory que é um Singleton que recebe em seu método getInstance() o tipo de gerador a ser construído. Complementando, consiste de um Singleton que também é uma Fábrica Parametrizada de geradores de programação.
Um gerador de programações recebe um visitante (Design Pattern Visitor) que vai informar se a data da programação gerada está de acordo com seus requisitos. Por exemplo: se quisermos gerar programações que não ocorram nos finais de semana, passa-se um visitante que não permite tal inclusão.
