What is a GRASP controller?

Question

What is the idea behind the Grasp Controller template?

My current interpretation is that sometimes you want to achieve something that needs to be used for several classes, but none of these classes could or did not have access to the information needed for this, so you create a new class that executes this work, having links to all the necessary classes (this can be an information expert).

Is this the correct idea of ​​what a Grasp controller is?

Typically, when googling or a SO'ing controller, I just get results about MVC (and something else), which are topics that I don’t understand, so I would like to get answers that do not assume that I know ASP.NET MVC or something: (

thanks

Answer 1

According to Wikipedia :

Controller object - a non-user interface object that is responsible for receiving or processing a system event.

From Using UML and Templates :

What is the first object outside the user interface layer that first receives and coordinates ("controls") the system?

Controllers in all directions - whether in MVC or GRASP or EAA Templates - are all about how to get input and respond to events.

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

It responds to input events - pressing user buttons. He doesn’t necessarily know what to do when you press a button, but at least he gets an event.

Looking at the controller, you can easily understand what system events are, that is, what input data it reacts to and how the user interacts with the system. On a Nintendo controller, it’s obvious that system events are:

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

If we took all these events and built a software controller to deal with them, it would be an MVC controller: all these events are connected to the physical controller presented to the user - this is a “view” if you will. But there is a second level of input events for most video games, where the mashing button is mapped to specific system operations. For example, if you play Scorpion in Mortal Kombat 2, pressing ← ← B triggers one of your special moves. In this case, the system may require different controllers that deal with these different types of events:

Here, the NES Button Controller is an MVC controller that will monitor the state of user interface elements, for example, remembering which buttons were pressed in which order. Depending on the state of the application (see Application Controller - another one!) The NES Button Controller will respond to certain button combinations by calling methods on other controllers - for example, the Scorpion Controller - which are the controllers of the used case.

The important thing is that by looking at the design of these controller objects, you can quickly and easily list the system events to which they respond.

In general, in the end, the MVC controller is still a kind of GRASP controller, since its methods, as a rule, represent system events that respond to user input. But there are other GRASP controllers that are not MVC controllers: use Case controllers. A GRASP-based Case controller can respond to system events, such as "the user creates a new sale," while the MVC controller will respond to events such as "the system receives a PUT request for /sales/new " or "a java.awt.event.ActionEvent fires` ".

Answer 2

Models contain data. Views represent data.

Views listen to models using the Gang of Four Listener template.

Controllers decide what to do with user input. Or they call methods on models, build new objects in the current set of models, delete objects from the current set of models, rewrite representations in different models, add views, delete views, or reconfigure views.

GRASP is just a tool for a better understanding of software and, I hope, does not allow making blatant mistakes when creating new software due to good design practice. 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 is not polluted by code that handles the display details. This way you can isolate the "business logic" or "what the class should do" inside the model. Representations respond to changes in the model because the model conveys messages to each representation that has established itself in relation to the model (listener template). Messages are often quite brief, basically you do not need to contain any data other than the “modified model”.

When the views are notified that a change has occurred in the model, the view then receives the necessary data from the model’s public interface. After the view has the data it needs, it displays the data to the user (using any interface designed for support). This isolates the presentation of the data to the class, which is interrupted when the view is changed incompatibly, and allows you to change the view code without a model class that requires modification of "compatibility".

The controller is responsible for knowing where the focus is, and which model or view for updating. This is a glue that combines things and is responsible for the correct processing of input.