对象更多是关于行为还是数据？从外部看，数据是隐藏的，行为是公开的。我们看到投入转化为产出。但看不到任何倍隔离的数据；我们也不知道这些数据的存储位置或存储方式。
数据库表更多是关于行为或数据信息？它们是简单的数据结构。从外部看，数据是暴露的，没有任何行为，无论可见或隐含的行为。
对象和数据结构是相互补充的。它们是正交的：隐藏数据和暴露行为；或者，暴露数据和无可见行为。
我们使用具体的if /else/switch语句区分数据结构类型。我们通过抽象多态性来区分对象类型。依赖关系的方向彼此相反。这对计划组织具有深远的影响。
在任何一个程序中，如果将新数据类型添加到现有行为中，则对象是首选的组织方式，因为添加子类比更改过多的switch语句要容易得多。
在任何一个程序中，如果将新行为添加到现有数据类型，则首选数据结构；因为添加一个switch语句比更改层次结构中的过多子类要容易得多。
因此，在您的系统中，哪种更改的频率更高？您是更频繁向现有数据添加新行为，还是更频繁向现有行为添加新数据类型？而且，也许更重要的是，根据作用域权衡。
假设：在代码的最低级别，我们倾向于将新行为添加道现有数据类型。在体系结构架构级别，我们倾向于将新的数据类型添加到现有行为中。如果这个假设为真，则此推测表明，最好围绕if/else/switch逻辑组织低级代码，而最好围绕多态性组织体系结构和架构。
众说纷纭：
这个观点有趣，也许解释了：为什么对象范例中的许多方法都是公开数据的简单获取getter()和设置操作setter()的原因。而在数据库表世界内，通常将存储过程和触发器（代表行为）添加到DBMS。如何融合它们... （banq注：无法融合，两种世界观）
我正在一个旧系统上工作，在该系统上许多数据结构都暴露在外。这是一场灾难。
对象最好是关于保护数据完整性的。您可以通过组织与该数据的交互来确保这一点。
两者，但并非总是同时。我倾向于使用最低级别的应用程序组织我的应用程序，其中包含一个数据对象和一些独立的行为类，例如验证。它们被卡在一个幕墙后面，该幕墙将这些定义组合成一个可配置的整体。有些人可能会认为这是“贫血模型”。我只是应用SRP和DI来创建可测试的，可组合的领域模型。
数据存储和数据处理应该有明显的区别。这样一来，当需要在2040年用SuperDatastoreX淘汰MSSQLs时候，团队不会再对你的名字吹气了，因为您“对数据库进行了编程”。
15年了，我从未见过有人真正改变过他们的存储系统