oop - 基于责任的建模与改变的类原因

Question

在这篇文章中，我读到

警惕一个只是荣耀责任的组件。组件应该捕获在系统中有目的的抽象。有可能在某一时刻作为一个有意义的组件出现实际上只是一个单独的责任。该责任可以分配给一个组件。

这让我很困惑。如果一个类应该只有一个改变的理由，它似乎应该有一个责任。但现在看来我把这个太窄了。在基于责任的建模的背景下，能否以某种方式解释责任和改变的理由？一个类是否可以有两个以上的职责，并且仍然有一个改变的理由（或相反）？

Answer 1

阅读关于 Class-Responsibility-Collaboration 建模（或设计）的信息

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 的以下短语：“组件应该捕获在系统中有目的的抽象”。系统中的目的（改变的原因）与满足用户目标（责任）的目的不同。

长话短说：就我的理解而言，理想情况下，组件具有一个核心概念。它可能有几个职责。但在我看来，一项职责可能不会分配给多个组件。