问题标签 [grasp]

我在学校学习 GRASP 模式，我对 Creator 模式有疑问。

假设您有三个类，Computer，UserRespository和User。

GRASP Creator 模式的规则之一告诉您将创建对象的责任分配给包含这些对象的类。按照这个指南，UserRepository 应该是 User 的创建者。

所以如果Computer想要创建一个用户，他会询问UserRespository。

这有效地将Computer与User解耦。真的吗？

显然，Computer没有提到 User，但我认为 Computer 仍然与 User 的创建高度耦合。为什么？createUser方法很难隐藏创建。如果User更改它的构造函数，您必须更改createUser方法以反映这些更改以及使用该方法的每个客户端。

那么使用这种模式有什么好处呢？

我有一个可以处于多种状态的域模型，如果这些状态超出给定范围，域应该会自动做出反应。

例如，我有一辆汽车，它由多种具有测量值的东西组成

发动机 - 转速计数器和温度

油箱 - 容量

有一个 CarStateController 是合理的，它可以观察发动机和油箱，如果这些状态超出范围，即发动机温度高于范围，请打开发动机风扇。

没有 UI，（您可能会争辩说它会在仪表板上显示灯，但在这种情况下它不会）这是对 GRASP 控制器模式的有效使用吗？如果不是，这个 CarStateController 叫什么？

还是我完全错过了重点，这应该是状态模式？

在 .net 中使用外观控制器模式。似乎它效率不高，因为对于域对象（销售、注册、计划、汽车）中发生的每个事件，它必须由控制器（用例控制器）订阅，然后控制器依次具有复制同一事件以使其可用于演示文稿，以便演示文稿可以将其显示给用户。这有意义吗？请给出意见！

Grasp 的控制器模式背后的想法是什么？

我目前的解释是，有时您想要实现需要使用几个类但这些类中没有一个可以或无法访问执行此操作所需的信息，因此您创建一个完成这项工作的新类，并引用所有需要的类（这可能是信息专家）。

这是对 Grasp 控制器的正确看法吗？

通常在谷歌搜索或 SO'ing 控制器时，我只会得到关于 MVC（以及诸如此类）的结果，这些都是我不了解的主题，所以我想要不假设我知道 ASP.NET 的 MVC 或其他东西的答案： (

谢谢

我真的对 GOF 和 GRASP 模式之间的区别感到困惑吗？甚至两者都有助于改进面向对象的实践

我已经使用 Java 编写了一个任务管理器程序，并暂时制作了一个 UI 实现。该程序目前有 3 层。通过用例控制器与域层交互的表示层，最后是用于持久性的技术服务层。在这一点上，用户可以执行多种操作，例如添加任务、编辑任务状态等……我在此方案中记录器的目的是跟踪用户执行的所有操作。所以，有几个地方我可以调用记录器来编写命令。我不会在表示层中进行任何日志记录，因为这将是一个糟糕的设计决策，所以我只剩下控制器、命令接口（为了实现撤消/重做功能而实现处理所有命令的执行） ),

我认为控制器是一个相对不错的选择，因为它充当 UI 层和域之间的联系点，因此所有值得注意的命令最终都通过控制器，从而可以轻松验证所有重要方法是否正在被记录. 不在控制器中这样做的一个原因是它会降低内聚，增加耦合并可能导致控制器臃肿。

具体命令是另一个潜在的位置，因为它们也具有日志记录所需的所有信息。这将再次导致命令变得不那么内聚并增加耦合。此外，如果我不使用命令界面对域对象执行操作，那么我会丢失日志记录。

最后，这导致我在较低级别的域对象方法中实现记录器。这是一个很好的选择，因为如果正在使用该程序并且所有需要的信息都可用，那么日志总是会发生。唯一不利的部分是记录器命令将稀疏地分散在较低级别的域对象中，这使得确保记录所有正确的方法变得更加困难。

我很乐意就此类决定进行辩论，并感谢您的所有评论。

作为一名设计师，我喜欢提供满足功率/简单性平衡的界面。例如，我认为 LINQ 设计者遵循了这一原则，因为他们提供了点表示法和查询表示法。第一个功能更强大，但第二个更易于阅读和遵循。如果您不同意我对 LINQ 的评估，请尝试理解我的观点；LINQ 只是一个例子，我的帖子不是关于 LINQ。

我把这个原则称为“可拨号电源”。但我想知道其他人怎么称呼它。当然有些人会说“KISS”是常用词。但我认为 KISS 是一种超集，或一种“消费主义”实践。再次使用 LINQ 作为我的示例，在我看来，一个总是尝试使用查询表示法而不是点表示法的程序员团队正在练习 KISS。因此，LINQ 设计者实践了“可拨号电源”，而 LINQ 消费者实践了 KISS。两人一起创作美妙的音乐。

编辑我再举一个例子。想象一个日志工具有两个签名，允许两种用途：

这两个签名的目的是满足这些需求：

拥有这些重载代表“可拨号能力”，因为消费者可以选择简单接口或功能强大的接口。喜欢 KISS 的消费者大部分时间会使用更简单的签名，并在需要电源时允许看起来“忙碌”的签名。这也有助于自我记录，因为使用强大的签名会告诉读者代码对性能至关重要。如果记录器只有强大的签名，那么就没有“可拨电源”。

所以这是一个完整的循环。如果尚不存在的话，我很乐意保留我自己的“可拨号电源”造币，但我不禁认为我错过了这种做法的明显名称。

ps 另一个相关但与“可拨号电源”不同的例子是 Scott Meyer 的原则“使接口易于正确使用，而难以错误使用”。

我认为服务/应用程序层与 Larman 描述为 GRASP 控制器的东西相同，它是 GUI 层之外的第一个对象，它委托给领域层，并且应该可以从不同的 GUI 重用。

服务（Evans）层与应用程序（Fowler）层相同，因为 Fowler 自己在他关于“贫血域模型”的“bliki”中这么说：http ://martinfowler.com/bliki/AnemicDomainModel.html

引用：“应用层[他的名字为服务层]：定义软件应该做的工作并指导表达域对象解决问题。该层负责的任务对业务有意义或与交互是必要的其他系统的应用层。这一层保持薄。它不包含业务规则或知识，而只是协调任务并将工作委托给下一层领域对象的协作。它没有反映业务情况的状态，但它可以具有反映用户或程序任务进度的状态。”

现在考虑上述描述（另请参阅 fowler 的 PEAA 书，关于从用例中识别服务层方法），并考虑 Fowler 对服务层的描述中的图片，该图片说明服务层是“用户界面”之后的第一层这个网址：http ://martinfowler.com/eaaCatalog/serviceLayer.html

现在将上面提到的服务/应用层描述与拉曼关于 GRASP 控制器的一些话（在他最畅销的 OOAD 书籍“应用 UML 和模式”的第 3 版，年龄 302-306）中进行比较：“......第一个对象除了接收和协调（“控制”）系统操作的 UI 层之外……” “……表示系统事件发生的用例场景……” “…… 通常，控制器应该委托给其他对象需要完成的工作；它协调或控制活动。它本身并没有做太多工作......”

我认为 Larman 的 GRASP Controller 层与 Evans/Fowler 的 Application/Service 层相同。其他人不同意吗？然后请解释这些概念之间的显着差异，以及控制器类而不是服务/应用程序类的一些示例。

我的问题诞生了，因为有人说模型域对象的创建是控制器的责任，而不是其他服务/应用程序层。但是你能给我一个服务层类和控制器类之间的区别的例子吗？

GRASP Creator 与依赖注入完全矛盾吗？

如果不是，请解释原因。

我有一个作业，我需要根据 GRASP 评估哪种方法更好。

我发现这个链接回答了我的部分问题：为什么在 C++ 中有头文件和 .cpp 文件？

但是，我想知道的是，由于所有内容都在联合文件中定义，因此 C++ 的工作方式在可扩展性和代码重用方面比 JAVA 更好吗？

谢谢您的帮助 ！

编辑：只是为了确保这不是一场辩论，我想知道为什么 JAVA 不像 C 语言那样做，并促进类定义和类实现之间的分离。这种工作或处理方式有什么好处吗？

此问题已移至https://softwareengineering.stackexchange.com/questions/118574/does-java-promote-a-separation-between-class-definitions-and-implementations-as