Search code examples
c#javadesign-patternscontrollergrasp

What exactly is GRASP's Controller about?

What is the idea behind Grasp's Controller pattern?

My current interpretation is that sometimes you want to achieve something that needs to use a couple of classes but none of those classes could or has access to the information needed to do it, so you create a new class that does the job, having references to all the needed classes(this is, could be the information expert).

Is this a correct view of what Grasp's Controller is about?

Generally when googling or SO'ing controller, I just get results about MVC's (and whatnot) which are topics that I don't understand about, so I'd like answers that don't assume I know ASP.NET's MVC or something :(

Thanks

Solution

  • According to Wikipedia:

    A Controller object is a non-user interface object responsible for receiving or handling a system event.

    From Applying UML and Patterns:

    What first object beyond the UI layer first receives and coordinates ("controls") a system operation?

    Controllers, across the board - be it in MVC or GRASP or Patterns of EAA - are all about receiving input and responding to events.

    I conceptualize it very literally: think of a video game controller. NES controller

    It responds to input events - the user pressing buttons. It doesn't necessarily know what to do when you hit a button, but it at least receives the event.

    Looking at the controller, one can easily figure out what the system events are - that is to say what inputs it responds to and how the user interacts with the system. On a Nintendo Controller, it's evident that system events are:

    • Press A
    • Press B
    • Press X
    • Press Y
    • Press ↑
    • Press ↓
    • Press →
    • Press ←
    • Press L
    • Press R

    If we were to take all these events and build a software controller to deal with them, it would be an MVC controller: these events are all concerned with the physical controller as presented to the user - it's "view", if you will. But there's a second layer of input events for most video games, where button mashing maps on to specific system operations. For example, if you're playing as Scorpion in Mortal Kombat 2, pressing ← ← B triggers one of your special moves. In that case, the system could need different controllers which deal with these different kinds of events:

    UML diagram of various controller classes - a Button Controller with methods for each button press, and then various controller objects for different playable characters. Each player controller exposes methods corresponding to the character's special moves.

    Here, the NES Button Controller is a MVC controller which would keep track of the state of UI elements - for example, remembering what buttons were pressed in what order. Depending on application state (see Application Controller - another one!) the NES Button Controller would response to certain button combinations by invoking methods on the other controllers - for example the Scorpion Controller - which are Use Case Controllers.

    What's important is that by looking at the design of these controller objects, you can quickly and easily enumerate the system events they respond to.

    Altogether, in the end, the MVC Controller is still a kind of GRASP Controller - as its methods tend to represent system events, which respond to user input. But there are other GRASP controllers which are not MVC controllers: Use Case controllers. A GRASP Use Case controller might respond to system events such as "user creates a new sale" while an MVC controller would respond to events like "system receives a PUT request for /sales/new" or "a java.awt.event.ActionEvent fires`".