GRASP 的控制器到底是做什么用的？
Grasp 控制器模式背后的想法是什么？
我目前的解释是，有时您想要实现需要使用几个类的东西，但这些类都不能或无法访问执行此操作所需的信息，因此您创建一个新的类来完成这项工作，并引用所有需要的课程（这可能是信息专家）。
这是对 Grasp 控制器的正确看法吗？
一般来说，当谷歌搜索或 SO'ing 控制器时，我只会得到有关 MVC（以及诸如此类的）的结果，这些是我不理解的主题，所以我想要的答案不假设我知道 ASP.NET 的 MVC 或其他东西： （
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据维基百科：
来自应用 UML 和模式：
全面的控制器 - 无论是 MVC 或 GRASP 还是 EAA 模式 - 都是关于接收输入并响应事件。
我从字面上理解它：想象一个视频游戏控制器。
它响应输入事件 - 用户按下按钮。当您按下按钮时，它不一定知道要做什么，但它至少会收到事件。
查看控制器，我们可以轻松地弄清楚系统事件是什么，也就是说它响应什么输入以及用户如何与系统交互。在任天堂控制器上，很明显系统事件是：
ABXY↓→←LR我们要获取所有这些事件并构建一个软件控制器来处理它们，那么它将是一个 MVC 控制器：这些事件都与呈现给用户的物理控制器有关 - 如果您愿意的话，它是“视图” 。但大多数视频游戏都有第二层输入事件，其中按钮组合映射到特定的系统操作。例如，如果您在《真人快打 2》中扮演蝎子，按
← ← B会触发您的特殊动作之一。在这种情况下，系统可能需要不同的控制器来处理这些不同类型的事件：这里，
NES 按钮控制器是一个 MVC 控制器。将跟踪 UI 元素的状态 - 例如，记住按什么顺序按下了哪些按钮。根据应用程序状态（请参阅应用程序控制器 - 另一个！）NES 按钮控制器将通过调用其他控制器上的方法来响应某些按钮组合 - 例如Scorpion Controller- 这是用例控制器。重要的是，通过查看这些控制器对象的设计，您可以快速轻松地枚举它们响应的系统事件。
总而言之，MVC 控制器最终仍然是一种 GRASP 控制器 - 因为它的方法倾向于表示系统事件，从而响应用户输入。但还有其他不是 MVC 控制器的 GRASP 控制器：用例控制器。 GRASP 用例控制器可能会响应诸如“用户创建新销售”之类的系统事件，而 MVC 控制器可能会响应诸如“系统收到
/sales/new的 PUT 请求”或“ajava.awt.event.ActionEvent触发`"。According to Wikipedia:
From Applying UML and Patterns:
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.
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:
ABXY↑↓→←LRIf 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
← ← Btriggers one of your special moves. In that case, the system could need different controllers which deal with these different kinds of events:Here, the
NES Button Controlleris 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!) theNES Button Controllerwould response to certain button combinations by invoking methods on the other controllers - for example theScorpion 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 "ajava.awt.event.ActionEventfires`".模型包含数据。视图呈现数据。
视图监听模型，使用四人组监听器模式。
控制器决定如何处理用户输入。它们可以调用模型上的方法、在当前模型集中构造新对象、从当前模型集中删除对象、将视图重新连接到不同的模型、添加视图、删除视图或重新配置视图。
GRASP 只是一种更好地理解软件的工具，并希望通过良好的设计实践防止人们在创建新软件时犯下明显的错误。它确实与MVC无关，但是可以用来更好地理解MVC。
MVC 中的关键是模型不会被处理显示细节的代码污染。这样您就可以单独隔离模型内部的“业务逻辑”或“类应该做什么”。视图对模型中的更改做出反应，因为模型会向每个已针对模型（侦听器模式）注册自身的视图发出消息。这些消息通常非常简洁，基本上不需要包含除“模型已更改”之外的任何数据。
当视图收到模型中发生更改的通知时，视图就会从模型的公共接口获取必要的数据。一旦视图获得了所需的数据，它就会向用户显示数据（使用视图支持的任何界面）。这将数据的呈现隔离到一个类，当视图不兼容地更改时，该类将中断，并且允许修改视图代码，而无需模型类需要“兼容性”修改。
控制器负责了解焦点所在以及要更新哪个模型或视图。它是将事物组合在一起的粘合剂，负责正确处理输入。
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.