基于责任的建模与阶级原因的变化

Question

在此文字中，我读了

  

警惕正常的组件   一个光荣的责任。一个   组件应该捕获一个   有目的的抽象   系统。它可能发生了什么   在某个时刻出现是有意义的   组件实际上只是一个单一的   责任留在自己身上。那   责任可以分配给   成分

这让我很困惑。如果一个班级应该只有一个改变的理由，那么它似乎应该有一个责任。但是现在我觉得这个太狭隘了。能否以某种方式解释在基于责任的建模背景下改变的责任和理由？一个班级有两个以上的职责，还有一个理由可以改变（或者反过来）吗？

Answer 1

了解课堂责任 - 协作建模（或设计）

http://www.agilemodeling.com/artifacts/crcModel.htm

http://alistair.cockburn.us/Using+CRC+cards

http://users.csc.calpoly。 EDU /〜jdalbey / SWE / CaseStudies / ATMSim / CRCmodel.html

http://c2.com/doc/oopsla89/paper.html

一个班级可能有几个职责。它总是代表一个单一的“东西”。

“改变的一个原因”规则不适用于责任。周期。

“改变的一个原因”规则应该如下使用。

1. 这并不意味着“1”。它意味着“尽可能少”。

2. 它适用于“界面”。或“基础抽象”或“概念”或“概念”为了一堂课。一个类应该包含很少的概念。当核心概念发生变化时，课程就会发生变化。

3. 许多简单的事情比一些复杂的事情要好。重新组合和修改简单的事情更容易。

4. 在每一个复杂的事情中都有许多简单的事情试图获得自由。

5. 很难定义“简单”，而是“一个概念”。很接近。 “改变一件事”也是对“简单”的有用测试。

6. 最后，“改变的一个原因”是字面意思不是“1”。

Answer 2

我理解它的方式，“赞美对组件的责任”的危险。意味着您需要小心不要直接将职责转移到系统组件。

例如，在电子邮件系统中，用户可以接近系统，目的是向接收者发起消息。系统有责任实现这一目标。

用户还可以接近系统以阅读和回复电子邮件。系统也有责任实现这一目标。

但这是否意味着需要有两个组件“发起新的电子邮件”。和“回复电子邮件”在系统中？不是。一般的“撰写电子邮件”组件将能够处理这两个要求。

因此，在这种情况下，组件“撰写电子邮件”。负责用户目标的“发起新邮件”和“回复邮件”。但如果其核心概念发生变化（“如何组成电子邮件”），它只需要改变。

仔细阅读Cockburn的以下短语：“组件应该捕获在系统中具有目的的抽象”。系统中的目的（改变的原因）与满足用户目标（责任）的目的不同。

长话短说：就我的理解而言，理想情况下，一个组件有一个核心概念。它可能有几个责任。但正如我所看到的那样，可能不会将一项责任分配给多个组件。