问题标签 [crc-cards]

我一直想知道人们如何使用 CRC（类责任协作）卡。我在书中读到过它们，在互联网上找到了模糊的信息，但从未真正掌握。我认为应该有人制作一个 youtube 视频来展示与 CRC 卡的会话，因为我的一本书将其描述为很难用文字表述，它应该“由已经掌握它的人教”。可悲的是，我知道附近没有人使用 CRC 卡，我想了解更多信息。

更新

任何显示人们使用此技术详细说明的视频的链接将不胜感激。

在 CRC 卡中，为什么我们要列出所有的合作者，而不是仅仅列出依赖关系。我的意思是如果 A 类调用 B 的函数，为什么在 B 类 CRC 协作者部分提到 A。如果我们简单地将 A 留在 B 的 CRC 卡中会更好，因为在 A 的 CRC 卡中 B 已经提到过。这样我们也可以从CRC卡中找出依赖关系，如果你知道A需要的B类的函数名，我们也可以在A的CRC卡中提及。通过快速生成类和序列图，这将更有帮助。通过在 A 合作者中提及 B 和在 B 合作者中提及 A 来实现什么特定功能？

假设我有三个类：User、Address 和 OrderProduct。

用户具有姓名、电话号码和地址等字段，其中地址是地址的一个实例。

如果处理产品订购的 OrderProduct 类需要存储在 User 中的地址，我是否只需将 User 列为协作者，还是需要将 Address 类包含为协作者，因为 User 类包含该地址？

CRC 卡被称为在创建系统之前模拟系统的简单、直观的方法之一。许多人用一些批评来赞扬它的优点，但我找不到关于它的实际用法或好的案例研究的好的、可靠的例子。

YouTube 只提供了两个如何使用 CRC 方法的直接示例 - 它们都在非美国播放，即使该方法的创建者是两个伟大的美国人^^。有多好笑？

所以在这里我想知道有多少人在设计会议中实际使用了 CRC？它仍然有效还是很棒？值得研究、练习和投入大量时间吗？

我一直在搜索（主要是 google）来尝试找到可以用来识别 SOA 服务的功能责任的工具或方法。我的搜索并没有真正想出任何东西。

目前，我用于确定职能职责的方法是临时的，实际上只是直觉，例如

• 所有与客户相关的功能都进入客户服务
• 所有与支付相关的功能都进入支付服务
• ETC

反思软件设计/架构领域中使用的其他方法：

1. 面向对象分析具有类责任协作（CRC）模型的概念来决定类的责任。

2. 据我了解，域驱动设计 (DDD) 具有有界上下文的概念，可以对域进行逻辑分区。

3. 在传统的软件架构中：

   • 《软件架构过程》一书与 CRC 有类似的方法，用于识别软件组件及其职责。
   • 基于架构的设计过程具有划分职责信息功能区域的步骤。

问题： SOA 架构师有哪些工具/方法可以让他们确定服务的功能职责？

我有一个关于模型视图控制器架构模式的类责任协作卡的快速问题：

为什么 Model 类的卡片不包含 View 和 Controller 类作为协作者？

谢谢！

我是一名信息工程专业的学生，​​正在准备考试。我必须将用例中的名词以项目符号列表的形式替换为使用 CRC 卡提取的类的名称。我遇到了麻烦，因为我不知道如何正确地做。

• 示例 A：“系统更新页面”->“图腾更新页面”

CRC 卡是否必须包含控制视图的类？此控件是否必须通过“控制器”类，如（在我的情况下）“连接”？

• 示例 A 2.0：“系统更新页面”->“图腾请求连接更新页面”

CRC 卡是否必须包含控制数据库的类？

• 示例 B：“系统在数据库中添加产品”->“连接添加对象产品到目录

有人可以帮助我了解如何正确执行此操作吗？对不起我的英语，对不起“奇怪”的问题

注意：所有示例都是我创建的，所以我不知道它们是否正确