基于责任的建模与变更的类别原因
在此文本中我读到
要警惕刚刚出现的组件 光荣的责任。一个 组件应该捕获 有目的的抽象 系统。可能会发生什么 在某个时刻显得有意义 组件实际上只是一个 责任自行留下。那 责任可以分配给 组件。
这让我很困惑。如果一个类应该只有一个改变的理由，那么它似乎应该有一个责任。但现在看来我的看法太狭隘了。能否在基于责任的建模背景下以某种方式解释责任和变更原因？一个类是否可以拥有两个以上的职责，并且仍然有一个理由进行更改（或反之亦然）？
In this text I read
Be alert for a component that is just
a glorified responsibility. A
component is supposed to capture an
abstraction that has a purpose in the
system. It may happen that what
appears at one moment as a meaningful
component is really just a single
responsibility left on its own. That
responsibility could be assigned to a
component.
This confuses me. If a class should have only one reason to change, it seems like it should have one responsibility. But now it seems I'm taking this too narrow. Can somehow give an explanation of responsibility and reason to change in the context of responsibility based modeling? Can a class have more than two responsibilities and still have one reason to change (or the other way around)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
了解类-责任-协作建模（或设计）
http://www.agilemodeling.com/ artifacts/crcModel.htm
http://alistair.cockburn.us/Using+CRC +卡片
http://users.csc .calpoly.edu/~jdalbey/SWE/CaseStudies/ATMSim/CRCmodel.html
http ://c2.com/doc/oopsla89/paper.html
一个类可能有多个职责。它总是代表一个单一的“事物”。
“改变的一个原因”规则不适用于职责。时期。
“变更的一个理由”规则应按如下方式使用。
这并不意味着“1”。它的意思是“尽可能少”。
它适用于类的“接口”或“底层抽象”或“概念”。一个类应该封装一些概念。当核心概念发生变化时，类就会发生变化。
许多简单的事情比一些复杂的事情要好。重新组合和修改简单的东西更容易。
在每个复杂的事物内部都有许多试图自由的简单事物。
很难定义“简单”，但“一个概念”很接近。 “改变一件事”也是对“简单性”的一个有用的测试。
最后，“一个改变的理由”并不意味着“1”。
Read about Class-Responsibility-Collaboration modeling (or design)
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
A class may have several responsibilities. It always represents a single "thing".
The "one reason to change" rule doesn't apply to responsibilities. Period.
The "one reason to change" rule should be used as follows.
It doesn't mean "1". It means "as few as possible".
It applies to the "interface" or "underlying abstraction" or "concept" for a class. A class should encapsulate few concepts. When that the core concept changes, the class changes.
Many simple things are better than a few complex things. It's easier to recombine and modify simple things.
Inside every complex thing are many simple things trying to be free.
It's hard to define "simple", but "one concept" is close. "one thing to change" is also a helpful test for "simplicity".
Finally, "one reason to change" doesn't literally mean "1".
按照我的理解，“美化对组件的责任”的危险意味着您需要小心，不要将责任直接转换为系统组件。
例如，在电子邮件系统中，用户可能出于向收件人发起消息的目的而接近系统。系统有责任使这一切成为可能。
用户还可以访问系统来阅读和回复电子邮件。系统也有责任让这一切成为可能。
但这是否意味着系统中需要有“发起新邮件”和“回复邮件”两个组件呢？不会。通用的“撰写电子邮件”组件能够满足这两个要求。
因此，在这种情况下，组件“撰写电子邮件”负责用户目标“发起新邮件”和“回复邮件”。但只有当其核心概念发生变化（“电子邮件的组成方式”）时，才需要进行更改。
再次仔细看看 Cockburn 的以下短语：“组件应该捕获在系统中具有用途的抽象”。系统中的目的（更改原因）与满足用户目标（责任）的目的不同。
长话短说：根据我的理解，一个组件最好有一个核心概念。它可能有多种职责。但在我看来，一项责任可能不会分配给多个组件。
The way I understand it, the danger of "glorifying a responsibility to a component" means that you need to be careful to not translate responsibilities to system components directly.
For example, in an email system, the user may approach the system with the goal of initiating a message to a recipient. It's the system's responsibility to make this possible.
The user may also approach the system to read and reply to an email. It's the system's responsibility to make this possible, too.
But does this mean that there need to be two components "initiate new email" and "reply to email" in the system? No. A general "compose email" component would be able to handle both requirements.
So in this case, the component "compose email" is responsible for the user goals "initiate new mail" and "reply to mail". But it would only need to change if its core concept changes ("how emails are composed").
Look again closely at the following phrase by Cockburn: "A component is supposed to capture an abstraction that has a purpose in the system". A purpose in the system (reason to change) is not the same as the purpose of satisfying a user goal (responsibility).
To make the long story short: As to my understanding, a component ideally has one core concept. It may have several responsibilities. But as I see it, the one responsibility may not be assigned to more than one component.