Grasp 的控制器模式背后的想法是什么?
我目前的解释是,有时您想要实现需要使用几个类但这些类中没有一个可以或无法访问执行此操作所需的信息,因此您创建一个完成这项工作的新类,并引用所有需要的类(这可能是信息专家)。
这是对 Grasp 控制器的正确看法吗?
通常在谷歌搜索或 SO'ing 控制器时,我只会得到关于 MVC(以及诸如此类)的结果,这些都是我不了解的主题,所以我想要不假设我知道 ASP.NET 的 MVC 或其他东西的答案: (
谢谢
Grasp 的控制器模式背后的想法是什么?
我目前的解释是,有时您想要实现需要使用几个类但这些类中没有一个可以或无法访问执行此操作所需的信息,因此您创建一个完成这项工作的新类,并引用所有需要的类(这可能是信息专家)。
这是对 Grasp 控制器的正确看法吗?
通常在谷歌搜索或 SO'ing 控制器时,我只会得到关于 MVC(以及诸如此类)的结果,这些都是我不了解的主题,所以我想要不假设我知道 ASP.NET 的 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.