people.relation.Love

2010-6-29

看到这个标题，经常写代码的兄弟们会不会觉得这很像是一个完整的类名（包名.类名）？这就是一个类，“恋爱”类。

首先我们应该明白，Love这个类是Relationship的一个子类，是一种人际关系。它的作用是封装恋爱中的两个People之间的通信数据，以及两个People互操作的一些方法。因此，只有同时用这个类来封装和解封装通信数据，这两个People才是坠入爱河，建立了恋爱关系。一方用Love来封装，一方用Classmate来解封装，这叫单恋，不算恋爱。

Love里都有哪些字段呢？

首先想到的，是一个People类型的字段：恋爱对象，有且仅有一个的字段。但实际上，恋爱对象这个People类的实例不是由Love类来定义、封装的，而是由Love类实例所在的上下文传入的。更明确的说，是由我们的大脑在维护“人际关系表”时，按照表中相关字段的定义来传入的。例如，一个People的“人际关系表”中部分字段如下：

那么，当我们与林黛玉交互数据时，我们会用Love类来进行封装；与薛宝钗交互时，会用Sister类；而与贾环、贾政交互时，则会使用Brother和Father类。

这意味着，一个People可以通过设定人际关系表，来用Love类封装多个人际关系。例如：

这时候，这个People就是大家眼中的花心大萝卜了。

类似的道理，爱的程度这个字段也是有人际关系表来维护的。因为，除了Love这种关系之外，其它的关系也有关系程度这一字段。与其将这个字段放在各个类中分别更新，不如统一由更高层的容器进行管理。

但是，是否初恋（isFirstLove）这个布尔型的字段，肯定是Love类的私有字段，并且，是Static修饰的静态字段。初恋只有一次，从第一个Love类实例创建的那一天，这个字段就被设置成了false，从此成为final，永不改变。

还有恋爱阶段（loveStep），也是Love的私有字段。这应该是一个枚举型的字段，包括热恋、退热、吵架、冷战等等。这个阶段的取值受温暖积分和伤害积分的影响，它也会影响到在处理双方关系时采用的方法，以及上下文环境中人际关系表的关系程度这个字段。

最重要的两个字段在这里出场了：温暖积分（warmScore）和伤害积分（hurtScore）。当对方传递过来的数据让自己感到温暖时，温暖积分就会自增；而当自己觉得受到伤害时，伤害积分就会自增。显然，我们都希望温暖积分高一些，伤害积分低一些。幸运的是，伤害积分会随着时间慢慢降低；不幸运的是，温暖积分也是这样。这就是所谓的时间能够抹平一切。但是，更加不幸的还在后面：温暖积分下降的幅度，或者说一阶导数，比伤害积分要高。这意味着，一段时间后，他/她对你的好可能已经被忘记，而他/她对你的坏，却仍被铭记于心。很无奈，但人性就是这样。

这两个积分的增减，受Love类中封装的恋爱双方互操作方法影响。这些方法本身可能很简单，打个电话问候一下，端杯开水，或者只是一句System.out.println("我爱你")。真正重要的是，你的系统为这些方法分配多少资源，尤其是cpu时间。这直接反应出用于维护你们恋爱关系的进程在系统中的进程优先级有多高，进而反应出你爱得有多深，也就是人际关系表中维护的那个爱的程度。其实反过来也一样：爱的程度越深，进程优先级越高，分配的资源也就越多。

也许反应快的人已经想到了：这岂不是一个循环？多分配资源→多执行进程→增加温暖积分→提高爱的程度→多分配资源→多执行进程……或者，用恶性循环来表达：少分配资源→少执行进程→增加伤害积分→降低爱的程度→少分配资源→少执行进程→……

这种循环很正常，辩证法中联系的观点，东方天人合一的观点，都可以拿来解释。咱们暂且把这些放在一边，仅用实用主义的观点来问一问：怎样跳出恶性循环？

强制改高人际关系表里的爱的程度这个字段取值呗！

后记：有一次在学校论坛上跟别人讨论单恋、暧昧算不算恋爱时候，我提出来只有双方都用Love来封装通信数据才能算恋爱。今天把这句话记录下来，再加上一小段后来乱想的，权且充数吧。