鲍勃大爷:对象是更关注行为,数据库表则是简单的数据结构,if/else/switch有使用依据

20-02-23 banq

对象更多是关于行为还是数据?从外部看,数据是隐藏的,行为是公开的。我们看到投入转化为产出。但看不到任何倍隔离的数据;我们也不知道这些数据的存储位置或存储方式。

数据库表更多是关于行为或数据信息?它们是简单的数据结构。从外部看,数据是暴露的,没有任何行为,无论可见或隐含的行为。

对象和数据结构是相互补充的。它们是正交的:隐藏数据和暴露行为;或者,暴露数据和无可见行为。

我们使用具体的if /else/switch语句区分数据结构类型。我们通过抽象多态性来区分对象类型。依赖关系的方向彼此相反。这对计划组织具有深远的影响。

在任何一个程序中,如果将新数据类型添加到现有行为中,则对象是首选的组织方式,因为添加子类比更改过多的switch语句要容易得多。

在任何一个程序中,如果将新行为添加到现有数据类型,则首选数据结构;因为添加一个switch语句比更改层次结构中的过多子类要容易得多。

因此,在您的系统中,哪种更改的频率更高?您是更频繁向现有数据添加新行为,还是更频繁向现有行为添加新数据类型?而且,也许更重要的是,根据作用域权衡。

假设:在代码的最低级别,我们倾向于将新行为添加道现有数据类型。在体系结构架构级别,我们倾向于将新的数据类型添加到现有行为中。如果这个假设为真,则此推测表明,最好围绕if/else/switch逻辑组织低级代码,而最好围绕多态性组织体系结构和架构。

众说纷纭:

这个观点有趣,也许解释了:为什么对象范例中的许多方法都是公开数据的简单获取getter()和设置操作setter()的原因。而在数据库表世界内,通常将存储过程和触发器(代表行为)添加到DBMS。如何融合它们... (banq注:无法融合,两种世界观)

我正在一个旧系统上工作,在该系统上许多数据结构都暴露在外。这是一场灾难。

对象最好是关于保护数据完整性的。您可以通过组织与该数据的交互来确保这一点。

两者,但并非总是同时。我倾向于使用最低级别的应用程序组织我的应用程序,其中包含一个数据对象和一些独立的行为类,例如验证。它们被卡在一个幕墙后面,该幕墙将这些定义组合成一个可配置的整体。有些人可能会认为这是“贫血模型”。我只是应用SRP和DI来创建可测试的,可组合的领域模型。

数据存储和数据处理应该有明显的区别。这样一来,当需要在2040年用SuperDatastoreX淘汰MSSQLs时候,团队不会再对你的名字吹气了,因为您“对数据库进行了编程”。

15年了,我从未见过有人真正改变过他们的存储系统

 

                   

1
猜你喜欢