物件更多是關於行為還是資料？從外部看，資料是隱藏的，行為是公開的。我們看到投入轉化為產出。但看不到任何倍隔離的資料；我們也不知道這些資料的儲存位置或儲存方式。

資料庫表更多是關於行為或資料資訊？它們是簡單的資料結構。從外部看，資料是暴露的，沒有任何行為，無論可見或隱含的行為。

物件和資料結構是相互補充的。它們是正交的：隱藏資料和暴露行為；或者，暴露資料和無可見行為。

我們使用具體的if /else/switch語句區分資料結構型別。我們通過抽象多型性來區分物件型別。依賴關係的方向彼此相反。這對計劃組織具有深遠的影響。

在任何一個程式中，如果將新資料型別新增到現有行為中，則物件是首選的組織方式，因為新增子類比更改過多的switch語句要容易得多。

在任何一個程式中，如果將新行為新增到現有資料型別，則首選資料結構；因為新增一個switch語句比更改層次結構中的過多子類要容易得多。

因此，在您的系統中，哪種更改的頻率更高？您是更頻繁向現有資料新增新行為，還是更頻繁向現有行為新增新資料型別？而且，也許更重要的是，根據作用域權衡。

假設：在程式碼的最低階別，我們傾向於將新行為新增道現有資料型別。在體系結構架構級別，我們傾向於將新的資料型別新增到現有行為中。如果這個假設為真，則此推測表明，最好圍繞if/else/switch邏輯組織低階程式碼，而最好圍繞多型性組織體系結構和架構。

眾說紛紜：

這個觀點有趣，也許解釋了：為什麼物件範例中的許多方法都是公開資料的簡單獲取getter()和設定操作setter()的原因。而在資料庫表世界內，通常將儲存過程和觸發器（代表行為）新增到DBMS。如何融合它們... （banq注：無法融合，兩種世界觀）

我正在一箇舊系統上工作，在該系統上許多資料結構都暴露在外。這是一場災難。

物件最好是關於保護資料完整性的。您可以通過組織與該資料的互動來確保這一點。

兩者，但並非總是同時。我傾向於使用最低階別的應用程式組織我的應用程式，其中包含一個資料物件和一些獨立的行為類，例如驗證。它們被卡在一個幕牆後面，該幕牆將這些定義組合成一個可配置的整體。有些人可能會認為這是“貧血模型”。我只是應用SRP和DI來建立可測試的，可組合的領域模型。

資料儲存和資料處理應該有明顯的區別。這樣一來，當需要在2040年用SuperDatastoreX淘汰MSSQLs時候，團隊不會再對你的名字吹氣了，因為您“對資料庫進行了程式設計”。

15年了，我從未見過有人真正改變過他們的儲存系統