我一直覺得基于domain的OOAD的設計思想有一個重大的缺陷,導致我們的設計靈活性很差。
OOAD有一個基本的前提:所以的類以及類之間的關系在設計完成后就已經確定了,不可以更改。我覺得正是這種“靜態性”導致靈活性很差。
比如:在domain層有一個Employee類,在設計的時候我們必須確定好:Employee有name和address等屬性,如果程序發布后用戶需要增加一個屬性,就不得不重新編譯代碼,這就是為什么有時候僅僅是數據庫表增加一個字段就會帶來如此大的工作量。我認為確定domain類屬性的工作應當由用戶做而不是程序設計師。不僅如此,甚至某些時候類和類之間的關系也不應該事先確定。比如Department和Employee的關系,有的公司是一對多,而有的公司是多對多。我覺得我需要一種“動態”性非常強的設計,才會滿足不同用戶的需要,才會真正設計出靈活性非常強的框架,后期的維護量才會最低。
可惜的是,我至今還沒有找到這樣一種框架,至少hibernate不能!
OOAD有一個基本的前提:所以的類以及類之間的關系在設計完成后就已經確定了,不可以更改。我覺得正是這種“靜態性”導致靈活性很差。
比如:在domain層有一個Employee類,在設計的時候我們必須確定好:Employee有name和address等屬性,如果程序發布后用戶需要增加一個屬性,就不得不重新編譯代碼,這就是為什么有時候僅僅是數據庫表增加一個字段就會帶來如此大的工作量。我認為確定domain類屬性的工作應當由用戶做而不是程序設計師。不僅如此,甚至某些時候類和類之間的關系也不應該事先確定。比如Department和Employee的關系,有的公司是一對多,而有的公司是多對多。我覺得我需要一種“動態”性非常強的設計,才會滿足不同用戶的需要,才會真正設計出靈活性非常強的框架,后期的維護量才會最低。
可惜的是,我至今還沒有找到這樣一種框架,至少hibernate不能!
安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢】