我一直觉得基于domain的OOAD的设计思想有一个重大的缺陷,导致我们的设计灵活性很差。
OOAD有一个基本的前提:所以的类以及类之间的关系在设计完成后就已经确定了,不可以更改。我觉得正是这种“静态性”导致灵活性很差。
比如:在domain层有一个Employee类,在设计的时候我们必须确定好:Employee有name和address等属性,如果程序发布后用户需要增加一个属性,就不得不重新编译代码,这就是为什么有时候仅仅是数据库表增加一个字段就会带来如此大的工作量。我认为确定domain类属性的工作应当由用户做而不是程序设计师。不仅如此,甚至某些时候类和类之间的关系也不应该事先确定。比如Department和Employee的关系,有的公司是一对多,而有的公司是多对多。我觉得我需要一种“动态”性非常强的设计,才会满足不同用户的需要,才会真正设计出灵活性非常强的框架,后期的维护量才会最低。
可惜的是,我至今还没有找到这样一种框架,至少hibernate不能!
OOAD有一个基本的前提:所以的类以及类之间的关系在设计完成后就已经确定了,不可以更改。我觉得正是这种“静态性”导致灵活性很差。
比如:在domain层有一个Employee类,在设计的时候我们必须确定好:Employee有name和address等属性,如果程序发布后用户需要增加一个属性,就不得不重新编译代码,这就是为什么有时候仅仅是数据库表增加一个字段就会带来如此大的工作量。我认为确定domain类属性的工作应当由用户做而不是程序设计师。不仅如此,甚至某些时候类和类之间的关系也不应该事先确定。比如Department和Employee的关系,有的公司是一对多,而有的公司是多对多。我觉得我需要一种“动态”性非常强的设计,才会满足不同用户的需要,才会真正设计出灵活性非常强的框架,后期的维护量才会最低。
可惜的是,我至今还没有找到这样一种框架,至少hibernate不能!
安徽新华电脑学校专业职业规划师为你提供更多帮助【在线咨询】