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

阅读有关类责任协作建模(或设计)的信息

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. 许多简单的事情总比一些复杂的事情好。重组和修改简单的东西更容易。

6. 最后,“一个改变的理由”并不是字面上的“1”。

按照我的理解,“美化组件的责任”的危险意味着您需要小心,不要将责任直接转化为系统组件。

例如,在电子邮件系统中,用户可以接近系统,目的是向收件人发送消息。让这成为可能是系统的责任。

但这是否意味着系统中需要有两个组件“启动新电子邮件”和“回复电子邮件”?不需要。一个通用的“撰写电子邮件”组件将能够处理这两个需求。

因此,在本例中,“撰写电子邮件”组件负责用户目标“发起新邮件”和“回复邮件”。但只有在其核心概念发生变化(“电子邮件的组成方式”)时,它才需要改变。

再仔细看一下Cockburn的以下短语:“组件应该捕获在系统中有用途的抽象”。目的 (更改原因)与满足用户目标(责任)的目的不同。

长话短说:据我所知,一个组件理想情况下只有一个核心概念。它可能有几个职责。但在我看来,一个责任可能不会分配给多个组成部分。