2009年6月29日 星期一

W25 My Object = Data + Behavior

在與兩位同事討論時,其中一位同事說,每個行為包裝為一個方法的想法很像Behavior Driven Design(後來查過資料,發現應更像先不看架構的責任導向設計--Responsibility Driven Design)。Object一直都是包含資料與行為,既然具有這兩類元素,Data Driven Design與Behavior Driven Design就應該同時注重。

角色、物件、大小事都對應到各自的Object(或是元件)並依其特性抽取共用是我的設計基礎,資料結構與處理步驟全採用一對一的對應設計是我的堅持,符合原始特性的定義才能夠將改變局部化到最小區塊,進而得到最少化的測試範圍。這些好處的相對代價是開發人員要額外作設計,必須花費較多的時間為自己與別人安排程式碼。

對於OOAD的題目,我一個人思考了兩年,提出的經驗與作法盡可能涵蓋到工作中所經歷到的各個角落。有一位喜歡看書的理論型同事是我經常討論的伙伴,從他那裡聽說到許多不用功就不會知道的名詞與作法;共事的同事們是我主要的經驗來源,由於他們現有的產出我才能明白各個角落的好處與缺失;專案上的同事則是我琢磨想法的對象,常問他們現在的作法與優缺點是什麼,同時提出我的作法詢問是否能留下好處並改善弱點。

每個地方的說法我都推論與驗證過,雖然能有可以解決的方案,但是我相信並不會是最佳的作法。許多同好都投注許多心力鑽研軟體工程的各個方面,沒有道理我只用兩個人年就有最後的結論。目前差不多是我的極限了,未來除了製作對應的工具之外,更需要的是有其他相信這一條路的人一同討論每個角落的最佳化。

這十年來在工作上所遇到能夠抱持相近努力方向的人,實在是屈一手之指可數呀。(當然不包含發現專案有問題時才喊著要好好設計口號、作下一個專案時又開始計較時程與產出的那些人)

2 則留言:

  1. 我是寫C的人...但衷心希望您能夠成功, 擺脫台灣做軟體的宿命

    回覆刪除
  2. 一般工程在A物件下可以接續的種類有限. 向下的B物件下若還有C物件, A物件是無法直接使用到C的, 但是在程式設計裡想使用誰就用誰. 無限種的使用可能形成了系統內部難以釐清的混亂.

    用層次來限制使用範圍一直都是趨勢, 投影片的01-07記錄我對這方面的想法. 假使程式設計的想法也可以用model來描述的時候, 是否同時表示它能夠被輸出為各種不同的語言實作?

    導引投影片完成後應能夠整理好想法. 屆時若還是認為此道可行, 我應會利用閒暇時間慢慢地堆積出這個龐大的工具作為在職場的最終產出....

    回覆刪除