假设您要在应用程序中创建银行帐户模型。您可以创建一个类BankAccount来执行典型的银行帐户。但是如果你被问到班上的责任是什么，答案是什么？ “像银行账户一样？”那不是很具体。 我对建模和责任之间的关系有点困惑。许多“现实世界”的物品似乎没有明确的责任。
开始对这些概念进行建模并保持明确责任的最佳方法是什么？
答案 0 :(得分：5)
分开“表现得像银行账户”的意思。银行帐户可能需要能够：
由此，您可以将这些任务（职责）中的一些（重构）抽象（重构）为更一般的模型，例如： “可以在不同权限级别进行身份验证的实体”，“可以在适当的权限级别与其类型的其他实体进行通信的实体”，“可以记录其状态发生变化且发生了哪些更改的实体”，等等。
在敏捷开发模型中，确定用户故事的用途是什么。但是，为了使用这种技术，你不必喝Agile kool-aid;它只是一种明智的方式来确定项目的要求是什么。批判性地检查用户将如何与您的软件进行交互，并具体定义这些交互将做什么，这是构建软件的第一步。
答案 1 :(得分：1)
银行账户责任示例，我的头脑：
答案 2 :(得分：1)
我在OOP设计过程中得出了一个结论，那就是认为太难以关于建模并不总是有效，因为它可能导致你无法解决问题。
良好模型的优点主要是可读性，可扩展性和可重用性。
首先考虑一下最终需要做什么，然后尝试将这些原则应用到您的模型中。不要太努力，如果你以后需要做一些重构，那就这样吧。你可能会失去太多宝贵的时间来围绕“完美”的模式。
至于银行帐户，请以这种方式考虑，如果您是银行家，您对实际帐户的期望是什么？然后尝试升级一个或多个空对象以慢慢满足要求。
您可以将模型视为具体定义 - 具有已定义行为的抽象形式。它的责任是这种行为的一部分，通常是外部世界可见的部分。
我看到它的方式，只有你可以在设计它时决定什么是正确的模型。
嗯，我的两分钱。
答案 3 :(得分：0)
“......许多'现实世界'的物品似乎没有明确的责任......”
请记住，当您编写软件时，您建模现实世界。模型可以是简单的或复杂的，对我们观察到的事物具有不同程度的保真度。重要的是捕获您尝试注入软件系统的行为。您可以自由地省略不能实现目标的功能。您也可以自由地“修改”没有物理类比的功能。
物理学中的模型也可以通过解释现象和预测新领域行为的能力来判断。软件模型的成功或失败是它能够模拟所需的行为并优雅地接受未来的变化。
请记住，有很多方法可以在软件中对任何系统进行建模。没有一个正确的答案。
答案 4 :(得分：0)
你的问题koen的问题在于你在创建课程后问它，实际上这是你在尝试创建新课时应该问自己的基本问题之一。
无论如何，我恭敬地不同意上述同事。 Meredith和Neil的答案定义了类合同，而非责任。班级责任被定义为班级提供的任何公共服务，而不考虑特定的实施。它取代了功能的概念，并且基本上非常简洁地描述了每个类的公共方法。所以类责任的例子可以是：
另一方面，类合同由类职责的总和来定义。 Meredith和Neil给出了一些例子。
答案 5 :(得分：0)
保持思维简单＆amp;大声思考。 用于识别职责的Thumb规则（从一组简单的操作开始）：
在建模对象上询问以下问题（实际上有很多问题）：
对象可以自己生存吗？或者它是交易工具？只有在处理其他对象时才有意义吗？ （依赖因素）
对象本身可以做什么？
其他对象可以对对象执行哪些操作？
可以对对象，数据或状态做些什么？
（即）帐户无法借记/贷记本身。这根本没有意义。 但它可以作为系统或银行家或客户借记/贷记的工具。
根据不同的观点，根据谁将使用此对象以及出于何种目的（即，来自银行家的眼睛，来自客户的眼睛，来自客户的眼睛的帐户对象）来识别行为。系统 - 等。）
“银行账户是客户与银行之间交易的常用工具 - 从不同角度使用它。银行将其用作管理客户资金的关键，同时客户将其用作工具交易“。
向客户存款/取款的是银行的借方/贷方。并且银行将出于各种内部目的使用该帐户（例如，通过警报通知客户他们的工资信用），而客户对该帐户的操作是有限的。
尝试形成简单的句子 - 与他人合作的对象 - 如果它们有意义，那么你就是好的。如果没有，请重新思考。
银行帐户，
欢呼声
-sundar