假设你想在应用程序中创建一个银行账户模型。你可以创建一个名为BankAccount的类，它会执行典型银行账户所做的事情。但是，如果有人问你这个类的职责是什么，答案是什么？“像一个银行账户一样运作？”那不是很具体。
我对建模和职责之间的关系有点困惑。许多“真实世界”的对象似乎没有明确的职责。
如何开始建模这些概念并保持明确定义的职责呢？
我对建模和职责之间的关系有点困惑。许多“真实世界”的对象似乎没有明确的职责。
如何开始建模这些概念并保持明确定义的职责呢？
6个回答
5
解析“像银行账户一样运作”的含义。银行账户可能需要能够：
- 跟踪它里面有多少钱
- 向拥有正确权限的人（账户所有者或银行员工）显示这些信息
- 接受存款
- 记录存款时间
- 向存款人提供已成功处理的确认信息（不同级别的权限，账户所有者可以得到新总额和确认号码，第三方只能得到确认号码）
- 为经过适当身份验证的用户提供资金（即处理提款）
- 记录提款时间
- 在余额不足时不会支付资金
- 从备用账户自动提取资金以进行透支保护
- 等等...
从中，可以将其中一些任务（职责）抽象出来，转化为更通用的模型，例如“能够根据不同权限级别进行身份验证的实体”，“能够与同类实体以适当的权限级别进行通信的实体”，“能够记录其状态何时发生变化以及发生了什么变化的实体”，等等。
在敏捷开发模型中，用户故事就是为了搞清楚这些任务是什么。然而，你不必遵循敏捷开发模式来使用这种技术；它只是一种合理的找出项目需求的方法。批判性地审查用户将如何与您的软件进行交互，并具体定义这些交互将做什么，是设计软件的第一步。
- Meredith L. Patterson
1
举几个银行账户的责任例子，我能想到的有：
- 维护账户持有人信息
- 维护交易清单
- 提供当前余额
- anon
2
看起來這是一份負責任的清單。但這意味著至少有3個對象。您是否在說“BankAccount”是一個太簡單的模型，而客戶端應該與TransactionList、Balance等對象進行交互？那麼整個類套件就是一個BankAccount模型了嗎？ - koen
不，它不是这样的。银行账户是一个单独的对象，有三个职责。几乎所有对象都有多个职责。银行账户可以使用交易列表（例如）来实现其中一些职责。 - anon
1
在面向对象编程设计中，我得出了一个结论，那就是有时候过度思考建模并不总是有益的，因为它可能会让你远离解决问题。
好的模型的优点主要在于可读性、可扩展性和可重用性。
首先，考虑最终需要做什么，然后尝试将这些原则应用到你的模型中。不要过度努力，如果需要稍后进行一些重构，那就这样吧。你可能会浪费太多宝贵的时间来理解“完美”的模型。
至于银行账户，可以这样考虑，如果你是一名银行家，你会期望从一个实际的账户中得到什么？然后尝试升级一个空对象或对象，以逐渐满足要求。
你可以将模型看作是一个具有定义行为的抽象形式。它的责任是该行为的一部分，通常是对外界可见的部分。
在我的看法中，只有你能在设计时决定什么是正确的模型。
这只是我的个人意见。
好的模型的优点主要在于可读性、可扩展性和可重用性。
首先，考虑最终需要做什么，然后尝试将这些原则应用到你的模型中。不要过度努力，如果需要稍后进行一些重构，那就这样吧。你可能会浪费太多宝贵的时间来理解“完美”的模型。
至于银行账户，可以这样考虑，如果你是一名银行家，你会期望从一个实际的账户中得到什么？然后尝试升级一个空对象或对象，以逐渐满足要求。
你可以将模型看作是一个具有定义行为的抽象形式。它的责任是该行为的一部分，通常是对外界可见的部分。
在我的看法中，只有你能在设计时决定什么是正确的模型。
这只是我的个人意见。
- Kenan E. K.
0
"...许多“现实世界”对象似乎没有明确的责任..."
请记住，当您编写软件时，您正在对真实世界进行建模。 模型可以简单或复杂，并具有不同程度的逼真度。 重要的是捕捉您试图注入到软件系统中的行为。 您可以自由地省略不推进目标的功能。 您也可以将没有物理类比的功能“具象化”。
物理学中的模型也是根据其解释现象和预测新领域行为的能力来评估的。 软件模型的成功或失败在于其模拟所需行为并优雅地接受未来更改的能力。
请记住，在软件中对任何系统建立模型都有许多方法。 没有一个唯一正确的答案。
- duffymo
0
你的问题，koen，是在创建类之后才问它，而实际上这是你在尝试创建新类时应该问自己的基本问题之一。
无论如何，我不同意我们上面同事的观点。 Meredith 和 Neil 的答案定义了 类合同，而不是职责。类职责被定义为类提供的任何公共服务，而不考虑特定的实现。它取代了 功能 的概念，并且基本上非常简洁地描述了每个类公共方法。因此，类职责的示例可能包括：
- 获取列表中的第一个元素
- 对债务列表进行排序
- 通知观察者类
另一方面，类合同由类职责的总和定义。 Meredith 和 Neil 给出了示例。
- Alexandre Bell
2
Meredith和我提供的例子是由经典OO技术CRC定义的职责。您似乎给同样的事情起了不同的名称。 - anon
请参考有关此事的参考书目。很抱歉，但我对我的答案有信心。我建议您查阅Meyers的《按合同设计》、Dewsbury和Dobson的《责任和可靠系统》以及Laender等人的《概念建模-ER 2000》等类似的书籍。您已经定义了类合同，这很好。但是在面向对象编程的上下文和语义中，它们不是职责。很抱歉。 - Alexandre Bell
0
保持思维简单并大声思考。 确定职责的基本规则（从一组简单操作开始）：
在建模对象上提出以下问题（实际上是很多问题）：
对象能否自行运作？还是它只是交易的工具？仅在与其他对象一起使用时才有意义？（依赖因素）
对象本身能做什么？
其他对象可以对该对象执行哪些操作？
可以对对象、其数据或状态进行哪些操作？
（例如）账户不能自行借记/贷记。那根本没有意义。 但它可以被用作系统、银行家或客户要借记/贷记的工具。
通过从不同的角度来看待对象，确定动作，根据谁将使用此对象以及出于什么目的（即，从银行家、客户、系统等的角度来看待账户对象）。
银行账户是顾客和银行之间进行交易的通用工具，两者从不同的角度使用它。银行将其作为管理客户资金的关键，而客户则将其作为交易工具。
对于客户来说，存款/取款就是银行的借记/贷记。银行会利用该账户进行各种内部用途（例如通过提醒通知客户发薪水），而客户的操作则受到限制。
尝试形成简单的句子，通过对象与其他人合作来传达含义 - 如果它们有意义，那就很好。如果没有，请重新考虑。
一个银行账户，
- 属于客户 - 可能会
- 存款
- 取款
- 查询余额
- 可以从他的账户开支票
- 可以向其他账户转账
- 可以支付账单
- 可以将工资存入账户
- 可以获得透支额度
- 属于银行 - 可能会
- 使用该账户作为跟踪账户资金和交易的工具
- 存储和维护所有账户和资金信息
- 限制账户持有人的访问并为其资金提供安全保障
- 等等。
谢谢
- Sundar
- RadicalFish
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接