什麼時候應該在OOP中創建對象？

Question

我試過尋找這個答案，但是這很難做到，很多問題都是關於如何創建類或者如何做特定的事情。我需要多一點實際的概述 - 我是自學成才的，我瞭解對象是什麼（以及如何創建它們），但我從來沒有看到何時創建對象的好解釋。

這可能聽起來像一個奇怪的問題，有一個答案沿「總是」的線，但我注意到，我的OOP代碼往往開始尋找程序在某個時刻。我該如何結合自己對兩種範例的理解，以便編寫結構良好的面向對象代碼？在某些時候，有一些主要的函數或代碼體需要創建變量和實例化對象，然後執行諸如執行條件測試等操作，所以我正在努力弄清楚應該將代碼作爲對象放入哪些內容。

也許答案是，我剛剛提到的所有這些點應該被另一個對象封裝。我不知道 - 這是我從理解的角度努力前進的地方。

Answer 1

這可能不太適合Stackoverflow，但這是一個非常好的問題，應該加以解決。你偶然偶然發現了一個編程中的常見問題：大多數「OOP」程序實際上並不是面向對象的。

OOP的重點在於封裝複雜性。艾倫凱最初從生物細胞的角度來設想它，細胞的所有機器都與外部世界隔絕，而且你只能通過輸入和輸出的信息與細胞相互作用。因此，一個對象封裝了一個完整的系統，並且本身將由對象組成，並且可以與其他對象組合成更大的對象。而且一切都會與消息溝通，沒有人能夠窺視其他任何人。這就是面向對象編程的含義，大量的寫作仍然受到這個想法的影響。但大多數自稱爲OOP的東西並不這樣做（做的這樣的工作現在通常被稱爲「Actor模型」，它可以是一種非常有效和可靠的編程方式，用Erlang等語言加以說明）。

今天大多數OOP系統認爲一個對象是一個不太有趣的事情（至少在我看來）：只是數據和方法的組合，可以作用於這些數據。行業內存在很大爭論，這是否是一個特別有用的構造（相對於從方法中分離數據的功能範式，或純粹集中於功能而非類的鴨子鍵入範例）。

但在實踐中，我會說在大多數情況下，我們創建對象有兩個原因：聚集數據並封裝責任。這些是非常不同的東西，但在許多流行的語言中，它們都被視爲「對象」。

在「叢塊數據」的情況下，當你有一個邏輯上應該合在一起的數據集合時創建一個新對象。例如，Point是兩個座標的集合，這是一個非常好的「數據對象」。

關於「封裝責任」，這指的是我們所說的「單一責任」原則。一個對象應該完全負責你可以命名的一個「事物」。例如，那個「東西」可能是「網絡連接」，或者可能是「畫這個窗口」。你有一個Connection類和一個Window類等等。真正的關鍵是命名。當你很容易命名它時，你知道你有一個好的課堂，並且它所做的一切似乎都是從你給它的名字開始的。當很難命名它時，你可能已經創建了錯誤的類。

類層次結構的關鍵教訓叫做替代原則（由Barbara Liskov形式化）。如果你打算創建一個子類，它必須能夠在任何地方使用它的超類可以被使用。所以Corgi IS-A狗，因爲狗可以做的一切，Corgi可​​以做。但是，令人驚訝的是，一個Square是而不是是一個Rectangle。矩形可以創建兩種長度。廣場不能。 Square-Rectangle問題可能是導致繼承錯誤的最常見原因。一個很好的教訓是遺傳是許多問題的錯誤工具。你應該喜歡結合多個對象而不是繼承。所以在創建新類時，淺層次往往是最好的。如你所發現的，你所看到的大部分叫做「OOP」的只是包含在對象中的程序性編程。這對新人來說非常混亂。我們這些幾十年來一直在做這件事的人很困惑。你只需要看看。