Pedro está trabalhando em um projeto de software orientado a objetos e especificou a classe Manage Schedules Handler que representa um tratador artificial de todos os eventos de sistema referente ao caso de uso Gerenciar Horários. Ao atribuir à classe Manage Schedules Handler essa responsabilidade, Pedro aplicou o princípio GRASP denominado
- A)controller.
Correta: o Controller do GRASP recebe e coordena os eventos do sistema relacionados a um caso de uso.
- B)creator.
Errada: creator trata de quem deve criar objetos, não de receber e encaminhar eventos do sistema.
- C)inheritance.
Errada: inheritance é um mecanismo de herança em OO, não um princípio GRASP para controle de eventos.
- D)flyweight.
Errada: flyweight é um padrão estrutural para economizar memória compartilhando estado, sem relação com casos de uso.
- E)template method.
Errada: template method define o esqueleto de um algoritmo, não a responsabilidade de atuar como controlador de eventos.
Gabarito: A
No GRASP, o padrão Controller ajuda a decidir quem vai receber e tratar os eventos do sistema quando uma interface dispara uma ação. Em vez de jogar essa responsabilidade em uma classe de domínio qualquer, você cria um objeto que funciona como ponto de entrada para o caso de uso, organizando o fluxo entre a interface e as demais classes. É como o “porteiro” do sistema: o evento chega, alguém recebe e encaminha de forma coerente. Na questão, a classe Manage Schedules Handler foi descrita exatamente como um tratador artificial de todos os eventos de sistema ligados ao caso de uso Gerenciar Horários. Isso é bem a cara de Controller: uma classe que centraliza o recebimento de eventos do sistema e coordena a execução da lógica do caso de uso. A ideia não é fazer o trabalho pesado de negócio, mas assumir a responsabilidade de coordenar. Esse padrão é clássico em análise e projeto orientados a objetos. Em muitas fontes de Engenharia de Software, o Controller aparece como o objeto responsável por representar o sistema ou um caso de uso e receber eventos vindos da camada de interface. Então, quando o enunciado fala em “tratador artificial de todos os eventos de sistema”, ele está praticamente piscando para você: é Controller mesmo. As outras opções misturam outros conceitos de OO e padrões de projeto, mas não têm relação com a função de receber e encaminhar eventos de um caso de uso. Aqui, o segredo é reconhecer a palavra-chave “eventos do sistema” e a função de coordenação. Não é sobre criar objetos, herdar comportamento ou usar um padrão de estrutura, e sim sobre controlar o fluxo do caso de uso.