¿De qué trata exactamente el controlador de Grasp?

Question

¿Cuál es la idea detrás del patrón del controlador de Grasp?

Mi interpretación actual es que a veces desea lograr algo que necesita usar un par de clases, pero ninguna de esas clases podría o tiene acceso a la información necesaria para hacerlo, para que cree una nueva clase que haga el trabajo, teniendo referencias a Todas las clases necesarias (esta es, podría ser el experto en información).

¿Se trata de una vista correcta de de qué se trata el controlador de GRASP?

En general, al buscar en Google o tal vez el controlador, solo obtengo resultados sobre los MVC (y otras cosas) que son temas de los que no entiendo, por lo que me gustaría respuestas que no asumen que conozco el MVC de ASP.NET o algo así: (

Gracias

Answer 1

De acuerdo a Wikipedia:

Un objeto de controlador es un objeto de interfaz que no es de usuario responsable de recibir o manejar un evento del sistema.

De Aplicar UML y patrones:

¿Qué primer objeto más allá de la capa de UI recibe primero y coordina ("controles") una operación del sistema?

Controladores, en todos los ámbitos, ya sea en MVC o agarre o Patrones de EAA - Se trata de recibir información y responder a los eventos.

Lo conceptualizo muy literalmente: piense en un videojuego controlador.

Responde a los eventos de entrada: los botones de presentación del usuario. No necesariamente sabe qué hacer cuando presionas un botón, pero al menos recibe el evento.

Mirando el controlador, se puede descubrir fácilmente cuáles son los eventos del sistema, es decir a qué entradas responde y cómo interactúa el usuario con el sistema. En un controlador de Nintendo, es evidente que los eventos del sistema son:

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

Si tuviéramos que tomar todos estos eventos y construir un controlador de software para tratarlos, sería un controlador MVC: todos estos eventos están preocupados por el controlador físico como se presenta al usuario, es "Vista", si lo desea. Pero hay una segunda capa de eventos de entrada para la mayoría de los videojuegos, donde los botones se mapearon en operaciones específicas del sistema. Por ejemplo, si estás jugando como escorpión en Mortal Kombat 2, presionando ← ← B desencadena uno de tus movimientos especiales. En ese caso, el sistema podría necesitar diferentes controladores que traten con estos diferentes tipos de eventos:

Aquí el NES Button Controller es un controlador MVC que realizaría un seguimiento del estado de los elementos de la interfaz de usuario, por ejemplo, recordando qué botones se presionaron en qué orden. Dependiendo del estado de aplicación (ver Controlador de aplicación - ¡Otro!) El NES Button Controller respondería a ciertas combinaciones de botones invocando métodos en los otros controladores, por ejemplo, el Scorpion Controller - que son controladores de casos de uso.

Lo importante es que al observar el diseño de estos objetos del controlador, puede enumerar rápida y fácilmente los eventos del sistema a los que responden.

En total, al final, el controlador MVC sigue siendo un tipo de controlador de agarre, ya que sus métodos tienden a representar eventos del sistema, que responden a la entrada del usuario. Pero hay otros controladores de agarre que no son controladores MVC: controladores de casos de uso. Un controlador de casos de uso de agarre podría responder a eventos del sistema como "el usuario crea una nueva venta", mientras que un controlador MVC respondería a eventos como "el sistema recibe una solicitud de apo /sales/new"o" un java.awt.event.ActionEvent incendios ".

Answer 2

Los modelos contienen datos. Las vistas presentan los datos.

Las vistas escuchan modelos, utilizando el patrón de la pandilla de cuatro oyentes.

Los controladores deciden qué hacer con la entrada del usuario. O llaman a métodos en los modelos, construyen nuevos objetos en el conjunto actual de modelos, eliminan los objetos del conjunto actual de modelos, vuelven a cablear vistas a diferentes modelos, agregan vistas, eliminan vistas o reconfiguran vistas.

GRASP es solo una herramienta para comprender mejor el software y, con suerte, evitar que uno cometa errores flagrantes en la creación de un nuevo software a través de buenas prácticas de diseño. Realmente no tiene nada que ver con MVC, pero se puede usar para comprender mejor MVC.

La clave en MVC es que el modelo no está contaminado con código que maneja los detalles de la pantalla. De esa manera, puede aislar la "lógica comercial" o "lo que se supone que debe hacer la clase" dentro del modelo solo. Las vistas reaccionan a los cambios en el modelo porque el modelo emite mensajes a cada vista que se ha registrado en el modelo (el patrón del oyente). Los mensajes a menudo son bastante breve, básicamente no necesitan contener ningún dato que no sea "el modelo ha cambiado".

Cuando se notifican a las vistas que se ha producido un cambio en el modelo, la vista adquiere los datos necesarios de la interfaz pública del modelo. Una vez que la vista tiene los datos que necesita, muestra los datos al usuario (utilizando cualquier interfaz que la vista debía admitir). Esto aísla la presentación de los datos a una clase que se romperá cuando la vista cambia de manera incompatible y permite la modificación del código de vista sin la clase de modelo que requiere modificaciones de "compatibilidad".

El controlador es responsable de saber dónde se encuentra el enfoque y qué modelo o vista actualizar. Es el pegamento que reúne las cosas y es responsable del manejo correcto de la entrada.