面向对象开发过程中对象的变迁污染与细化变质

面向对象开发过程中对象的变迁污染与细化变质

这是令我纠结的一个问题，至今尚未找到一个好的解决方案。

大家都明白，在面向对象的开发过程中，我们通常会从具体的业务逻辑中抽象出一个个对象来。在整个开发过程中，都会围绕这么写数据对象展开业务逻辑进行数据展现什么的。通常，我们还会将该数据对象映射到数据库中去存储。每一条记录对应的就是一个实例。而这个表就像是一个类一样。Ok，现在问题就出现了，随着项目的不断开发，需求不断变化，直到有一天，你发现以前抽象的数据类型发生变化了！单条记录不足以表征该对象，以前的记录现在需要细化，变成了好几条item，这几个item才能组成该记录。或者是干脆这个对象的概念因为某个需求而被更改了，就更悲剧。

举两个例子：

• 比如说，最初我要做一个闹钟程序。数据库中需要存储闹钟这个对象。这个闹钟和通常我们用的闹钟一样，可以设置模式。比如说周一至周五，或者周六周日。这样，数据库中存的对象其实就是某一种类型的闹钟。等到到时间后，我就根据该闹钟的information生成一个notify，进行提醒。Ok，现在数据库存储就是一个个闹钟对象，因为不可能存储notify对象啊，notify对象也是临时的持久数据，完成之后要销毁，而且这个notify也要随着时间的流失而增加。。    
   到某一天，需求变化了，我想要增加一个跳过功能。也就是说，比如说，老板说下周周末和下下周末要加班，那么我就可以在对应的闹钟上点击跳过两次。闹铃会在下下下周进行notify。现在的处理是，在数据库中增加SkipValue，去标记跳过几次，从而在提醒的时候根据该字段进行提醒判断。这样能够处理这个问题，但是关键问题是SkipValue值的增加导致原有本身的闹钟对象概念发生了变化，被污染了。原来的闹钟对象，表述就是该类型的闹钟的信息。SkipValue的增加，就好像使得原有Alarm概念变化了，存储的东西有点notify的概念，但是又不是真正的notify。当我们要获取距离现在最近的一个notify的时候，就会很费劲。原有的Alarm是一个持久性对象，然而加入SkipValue这个持久性的特征也被干扰了一些，我们不得不在必要的时候进行更新，而事实上这个闹钟本身并没有发生什么变化，变化的只是notify。。。。增加了SkipValue确实像在拆分Alarm为Notify。。。。如果数据库中能够存储notify，那么这个问题也就不存在了，skip本身也属于Notify的概念啊
  
   
• 现在要做一个个人生活的EventTracer。用以记录生活的各种琐事。Ok，那么面对的主要就是Event，比如说，某个Event表示PlayBasketball，或者表示Sleep。这个Event可能有开始时间，终止时间，备注，等等信息。
  可到后来，我在进行PlayBasketball的时候，还rest了10分钟，中间遇到老朋友，聊了20分钟的天，但整个过程都应该属于PlayBasketball的，而且我也需要记录rest的信息，聊天的信息。很明显，现在研究的对象已经细化了，原来是Event，现在应该是Record。若干Record共同构成一个Event，若干Record需要关联到一个Event上。那么现在的数据结构就不支持了。这个问题解决是可以解决。那就是更改数据库。增加表，增加字段。这样确实能够解决问题，而且也能够彻底解决问题。可在项目开发过程中，数据库升级太令人纠结了。而且是该项目已经发布了若干版本，已经有大量用户的情况下，升级一次，简直难上加难。总不能每次都发现有该问题后，再进行数据库升级。再者说来，对象发生了变化这是铁的事实啊。研究的对象，关注的对象发生了变化，对整个程序都会产生很大影响，不光光是数据存储，数据存储需要升级的原因本质上也是由于原有的抽象的对象已经不能满足当前的业务需求了，只有用最新的抽象对象取代原有的旧的数据对象，才能解决已发现和未发现的问题，更灵活的的满足新的业务需求。如何解决该类问题？还是当初设计的时候考虑不周全？纠结中。

 

上边举的两个例子，就是对这篇文章的说明，希望有经验的朋友指点一下，该类的问题你是怎么解决的，导致这样的问题出现的本质原因又是什么呢。。。说说你对此种现象的看法和思考。

Thks~！