为什么我们创建没有功能的对象？

Question

我是一种新的oop，我在想这是什么原因创建一个对象（如银行帐户或客户端地址），没有任何功能，除了设置和获取数据的属性方法？例如在现实生活中，客户端地址现在甚至不是物理对象，甚至银行账户，所以为什么PPL应该创建这些实体的软件版本？

预先感谢您

Answer 1

的原因是因为他们在具有性能世界实实在在的事情，和我们互动。在oop后面的整个想法是模型世界，因为它 - 在属性和相互作用方面。所以虽然地址或银行账户不一定是物理上有形，但它是东西存在，具有属性，并且我们与交互。通常我们想要模拟可以看作或多或少的独立实体，这些独立实体具有属性并且我们与进行交互。

以银行账户为例：银行账户有属性：它有一个账号，一个余额，一个所有者，一个交易清单。我们与它进行交互：我们进行存款，取款等。因此，我们将它建模为具有这些属性和操作（方法）的对象。不要让“对象”这个词限制你的思考只限于有形的东西。 “对象”可以是具有属性并且可以与之交互的实体。为了进一步扩大这一点，银行账户的“所有者”也应该成为一个对象。因为所有者具有属性：姓名，地址，电话号码等。银行可以与所有者交互，反之亦然。

要添加，也许是一个更具体的问题，为什么我们创建的对象“[不[]没有任何功能，除了财产方法”...让我们暂且搁置一个事实，现在银行帐户会除了财产方法之外，还有行为方法（存款，取款）......创建一个“银行账户”对象，假设只有属性方法（获取和设置属性）仍然给我们一个我们可以与之交互的对象。例如，我们有能力将银行账户（作为单一实体）从一个人转移到另一个人，或从银行的一个分行转移到另一个分行。它还使我们能够创建一整套银行账户（例如矢量或地图）来代表特定分行或属于特定客户的所有银行账户。 HTH。

---

在回答您的评论的问题

...但在现实中的银行帐户不存/取款， 这是银行柜员（真人或网上银行门）。 ..

我不是100％确定我理解你的评论问题，但会采取一个镜头。在oop中，我们也强调的两个概念是“抽象”和“松散耦合” - 抽象是从程序中不需要知道的部分隐藏实现的细节;和松耦合的意思是每个类独立存在并且不需要了解很多其他类，所以如果一个类发生了变化，那么使用或与该类交互的类也不需要改变（除非他们想要利用一些新功能;但如果他们不在乎，那么所有东西都保持向后兼容）。

以您的出纳员或客户经理为例，有时通过创建一个管理程序的大部分工作的类来简化程序的设计。然而，这必须与抽象概念和松散耦合相平衡。如果您向银行账户提供了一个名为makeDeposit（）和makeWithdrawal（）的方法，那么“任何人”都可以进行存款或取款：客户，柜员，atm等等，而您不需要了解详细信息（例如，维持平均余额，并计算赚取利息的天数等）。然而，如果Teller类拥有makeDesposit方法，那么Teller必须了解BankAccount的详细信息，违反了抽象和松散耦合的原则（Teller与账户紧密结合）。另一方面，如果您确实需要在您的程序中使用Teller类，则处理它并保持抽象和松散耦合的一种方法是让Teller的makeDeposit方法将工作简单地转发到BankAccount类（通过在帐户上调用makeDesposit）。确实BankAccount实际上没有存款，所以也许这只是为该方法选择一个更好的名称。也许调用BankAccount的方法“acceptDeposit（）”或“haveDespositMadeToMe（）”。这些只是命名细节。然而，实施应该允许客户将钱存入BankAccount，而不必担心更新该银行账户的内部细节（例如平均余额，存款日期，每个平均余额的利息天数等等）这就是为什么这种或那种方式（或带有一个名称或另一个名称）BankAccount本身应该有一个存款和取款的方法。这样，其他类别（包括柜员或AccountManager）在进行存款时不必担心BankAccount的内部情况。无论你想要什么，调用该方法。事实上，你可以争辩说BankAccount 和 Teller 都做不使存款，但只有“接受”他们;并最终只有客户存款。再次，只是命名。 HTH。

最后，在相关但不同的点，请记住，这个想法是模型世界（不重复它）。有时候，为了保持一个简单的程序，我们不一定要模拟世界的每一个细节。 只有完成我们希望我们的程序处理的用例需要的细节。 （例如，我们可以省掉出纳员，只允许客户直接进行存款或取款，而无需中间人）。这一切都取决于我们必须使用我们的程序处理的用例。一般来说，简单更好，除非简单不能充分做我们想要的程序。