What exactly is GRASP's Controller about?

Question

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

Answer 1

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 - a Controller is about receiving input.

Think of it very literally: think of a video game controller.

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

Looking at a controller, you can figure out what the system operations are. On a Nintendo Controller, it's evident that the inputs it responds to are: Press A, Press B, Press X, Press Y, Press ↑, Press ↓, Press →, Press ←, Press L, Press R.

Likewise looking at the following Controller, you could enumerate the system operations easily as well:

Altogether, in the end, the MVC Controller is still a GRASP Controller - as it's methods tend to be system operations, which respond to user input.

Answer 2

Models contain data. Views present the data.

Views listen to models, using the Gang of Four Listener pattern.

Controllers decide what to do with the user input. Either they call methods on the models, construct new objects in the current Set of models, remove objects from the current Set of models, rewire views to different models, add views, remove views, or reconfigure views.

GRASP is just a tool to better understand software, and hopefully prevent one from making blatant mistakes in the creation of new software through good design practices. It really has nothing to do with MVC, but it can be used to better understand MVC.

The key in MVC is that the model isn't polluted with code that handles display details. That way you can isolate the "business logic" or "what the class is supposed to do" inside the model alone. Views react to changes in the model because the model emits messages to each view which has registered itself against the model (the listener pattern). The messages are often quite terse, basically the don't need to contain any data other than "the model has changed".

When the views get notified that a change has occurred in the model, the view then acquires the necessary data from the model's public interface. Once the view has the data it needs, it displays the data to the user (using whatever interface the view was meant to support). This isolates the presentation of the data to a class which will break when the view changes incompatibly, and allows modification of the view code without the model class requiring "compatibility" modifications.

The controller is responsible for knowing where the focus lies, and which model or view to update. It's the glue that puts things together, and is responsible for correct handling of input.