数据和代码之间有什么区别？

举个例子,考虑超市购物者可以享受的一系列折扣.

我们可以将这些规则定义为某些标准方式的数据(合格项目列表,适用日期,优惠券代码),并编写通用代码来处理这些规则.或者,我们可以将每个代码编写为一大块代码,它会根据客户的购物清单检查相应的内容并返回任何适用的折扣.

您可以合理地将规则存储为对象,序列化为Blob或存储在代码文件中,以便每个规则可以选择自己在数据和代码之间的划分,以允许将来的规则不符合上面考虑的通用处理器的类型.

通过检查应该在文件或数据库中的6个不同的事物的if语句来批评混合数据的代码通常很容易,但是有一个规则有助于边缘情况吗？

或者这是面向对象设计的重点,让我们不要担心数据和代码之间的界限？

澄清一下,基本问题是:你如何编写上面的例子？是否有一条经验法则让您决定什么是数据？什么是代码？

(注意:我知道,代码可以编译,但在动态语言和JIT编译的世界中,即使这是一个模糊的概念.)

从根本上说,数据和代码之间当然没有区别,但对于真正的软件基础架构,可能会有很大的不同.除了明显的事情,如你所提到的,汇编,最大的问题是:

大多数足够大的项目被设计用于产生"一个大捆绑"的"释放",在3个月(或更长)的周期中生产,经过广泛测试,之后不能以严格控制的方式进行更改."代码"绝对无法更改,因此任何需要更改的内容都必须进行分解并制作"配置数据",以便更改它变得可以满足那些确保发布有效的工作.

当然,在大多数情况下,糟糕的配置数据可能会像坏代码一样彻底破坏发布,因此整个事情在很大程度上是一种错觉 - 实际上,它的代码或"配置数据"是否发生变化并不重要,重要的是主系统和变化的部分之间的界面是狭窄的,定义明确,足以让你很有可能做出改变的人理解他正在做的所有后果.

这已经比大多数人认为的更难了,因为它只是配置了几个字符串和数字(​​我亲眼目睹了生产大型机系统崩溃,因为它有一个布尔值设置与它正在讨论的另一个系统不同).当您的"配置数据"包含复杂的逻辑时,几乎不可能实现.但是情况不会更好,因为你使用设计糟糕的特殊"规则配置"语言而不是"真实"代码.

这是一个相当哲学的问题(我喜欢),所以我将以哲学的方式回答它:没有什么可以支持的.;)

数据是可以改变的系统的一部分.代码定义了行为; 数据转换为新数据的方式.

更准确地说:数据可以用两个部分来描述:描述数据应该表示什么(例如,具有名称和类型的变量)和值.变量的值可以根据代码中定义的规则进行更改.当然,描述不会改变,因为如果确实如此,我们会得到一条全新的信息.代码本身不会改变,除非需求(我们对系统的期望)发生变化.

对于编译器(或VM),代码实际上是执行其操作的数据.但是,要编译的代码没有指定编译器的行为,编译器自己的代码就是这样做的.