物件導向語言會將程式區分為稱為類別的模組。每個類別都包含功能，而功能由資料（欄位）和方法組成。（並非所有語言都使用這些術語，但它們適用於此處。）語言有各種規則，說明其他類別可以如何存取類別的功能，這些規則通常基於套用於類別的存取修飾詞。

在物件導向圈中爭論最久的論點之一，就是開放繼承和設計繼承之間的辯論。設計繼承的原則可能由Josh Bloch最能總結：「設計和文件化繼承，否則禁止繼承」。使用這種方法時，您必須仔細決定哪些方法可以繼承，並封閉其他方法，以防止它們被覆寫。

最近我經常看到 JSON 資料結構在伺服器中傳遞。JSON 文件可以直接儲存，方法是使用 AggregateOrientedDatabase 或關係資料庫中的 序列化 LOB。JSON 文件也可以直接提供給網路瀏覽器，或用於將資料傳輸到伺服器端頁面渲染器。當 JSON 以這種方式使用時，我聽到有人說使用物件導向語言會造成阻礙，因為 JSON 需要轉換成物件，然後再進行渲染，這浪費了程式設計的功夫。我同意浪費這一點，但我認為這不是物件的問題，而是未能理解封裝。

如果你學習物件導向設計，你會很快地了解到封裝資料非常重要。封裝最簡單的形式是使用存取器（取得和設定方法）或屬性，如果你的語言支援的話。（有些甚至在類別中執行此操作 - 自我封裝

在程式設計中，物件的基本概念是將資料和行為綑綁在一起。這在撰寫一組相關函式時提供了共同的資料脈絡。它也提供了一個用於處理資料的介面，讓物件可以控制對該資料的存取，這使得支援衍生資料和防止資料無效修改變得容易。許多語言提供明確的語法來定義類別，這些類別充當物件的定義。但是，如果你有一個具有第一類函式和閉包的語言，你可以使用這些結構來使用函式作為物件模式（最初由 Eugene Wallingford 描述）建立物件。

你可以從他們看到 getter 方法時嘴角左邊的抽搐來辨認他們，他們會迅速拉動他們的戰斧，並發出滿足的叫聲，因為另一個 getter 從一個類別中無情地砍下，而這個類別會立即在感激的 Getter 消滅者的腳下昏厥。

當人們說某個方法不會改變物件的可觀察狀態時，他們的意思是什麼？

這與 DesignedInheritance 的態度相反。開放繼承的倡導者不會透過 Seal 封裝他們的類別或採取其他措施來禁止繼承，以阻止人們繼承類別。

當您針對網頁撰寫測試時，您需要參照該網頁中的元素，以便按一下連結並判斷顯示的內容。但是，如果您撰寫直接操作 HTML 元素的測試，您的測試將會容易受到 UI 變更的影響。頁面物件會以應用程式特定的 API 封裝 HTML 頁面或片段，讓您可以在不深入探究 HTML 的情況下操作頁面元素。

模組化資訊豐富程式最常見的方法之一，就是將其分為三個廣泛的層級：簡報 (UI)、網域邏輯 (又稱商業邏輯) 和資料存取。因此，您經常會看到網頁應用程式分為知道如何處理 HTTP 要求和呈現 HTML 的網頁層、包含驗證和計算的商業邏輯層，以及整理出如何在資料庫或遠端服務中管理持續性資料的資料存取層。

在具有 受保護 存取修飾詞的類別中擁有資料，是否屬於良好的物件導向設計？

我第一次接觸 C# 時，從一開始就喜歡屬性的概念。C++/Java 的 getX 和 setX 約定俗成對我來說總是顯得有點愚蠢，寫成 obj.X = other.X 自然多了。提供具有 get 和 set 方法的屬性，會將常見的約定俗成轉變為語言的自然支援功能。

公開介面 是我用來指稱在定義它的程式碼庫外部使用的類別介面的術語 (首先在 重構 中使用)。因此，它的意義比 Java 中的 public 更廣泛，甚至比 C# 中的非內部 public 更廣泛。我在 IEEE Software 的專欄中論證，公開和 public 之間的區別實際上比 public 和 private 之間的區別更重要。

封閉方法或類別可防止子類別覆寫它。

資料封裝是物件導向風格的核心教條。這表示物件的欄位不應公開顯示，而應透過存取器方法（取得器和設定器）從物件外部存取。有些語言允許公開存取欄位，但我們通常會告誡程式設計師不要這麼做。自我封裝更進一步，表示對資料欄位的內部存取也應透過存取器方法進行。只有存取器方法才能觸及資料值本身。如果資料欄位未公開顯示，這表示必須新增額外的私人存取器。

自從我踏入這個領域以來，將軟體開發從費力地撰寫程式碼轉變為透過簡單組裝元件來建置強大系統的概念一直是目標。這個目標有時會一閃而過，但從未真正實現 - 儘管許多技術都曾拋出工業化重複使用的誘餌。

告訴，不要詢問是一個原則，有助於人們記住物件導向是關於將資料與對該資料進行運算的函式綑綁在一起。它提醒我們，我們不應要求物件提供資料並對該資料採取行動，而應告訴物件要執行什麼動作。這鼓勵將行為移至物件中，以搭配資料。

模組提供的所有服務都應透過統一表示法提供，不會洩露它們是透過儲存或運算來實作。

-- Bertrand Meyer

Bertrand Meyer 在他極具影響力的著作 物件導向軟體建構 中提出了此項原則。

此項原則的重點在於，如果您有一個 person 物件，並且詢問它的年齡，您應該使用相同的符號，無論年齡是物件的儲存欄位或計算值。這實際上表示，person 的客戶端不應該知道或關心年齡是儲存還是計算出來的。