爲什麼我們創建沒有功能的對象？

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。

最後，在相關但不同的點，請記住，這個想法是模型世界（不重複它）。有時候，爲了保持一個簡單的程序，我們不一定要模擬世界的每一個細節。 只有完成我們希望我們的程序處理的用例需要的細節。 （例如，我們可以省掉出納員，只允許客戶直接進行存款或取款，而無需中間人）。這一切都取決於我們必須使用我們的程序處理的用例。一般來說，簡單更好，除非簡單不能充分做我們想要的程序。