JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Software Design  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to postflat modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 設計常見問題
Joying





發文: 8
積分: 0
於 2007-12-24 00:16 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
I03.設計常見問題(1)──物件範圍沒有對應

有一種心理測驗是這樣的:在紙張印上一團不規則的黑色區塊,要人說出自己連想到的第一種物品,藉著幾種可能的答案來推測受試者心裡的想法。在設計Data Model時也有點像這樣;每個人都知道要根據Domain設計出系統專用的Data Model,可是同樣是專案的成員設計出來卻風格迥異。

舉個生活上的實例來看。客戶描述他們需要的是"椅子",藉由椅子可以提供他們靠著坐或可以站在上面拿高處的東西;需求講得很單純,於是A廠商想的椅子是一體成型的木椅(一個Class),B廠商想的是有滾輪與腳座的辦公椅(一個Class內含三個Class)。

當然兩種椅子都能符合客戶"目前的需求",不過客戶可能視臨時的需要而改變需求的內容;例如:客戶希望椅子是不能推動的,而且椅面距離地面的高度增加五公分等等。我們常去抱怨客戶亂改需求,但我們必須知道客戶大多是根據實際需要來改變小地方的;當然,要求改成按摩椅的類型真的就太過份,因為設計理念已經完全不同,怎麼改都會很淒慘。

回頭看合理的兩個小變更,A廠商的椅子本來就沒有輪子所以不用改(同時也慶幸不是改成加上輪子,不然真不能看),但是高度少的五公分該怎麼辦?要換掉四隻椅腳再釘回去好,還是在椅腳下加釘五公分木條好?要是長度再改變的話該怎麼辦?相對起來廠商B就好辦多了,要不要輪子,要多高的腳座都可以拆卸下來換成符合需求的物件;不過在需求沒改變時就相對地多花了不少功夫。

設計是為了應付未來可能的改變,所以我選擇的是廠商B的作法,儘可能地把一個物件拆成多個可抽換的組件,以期望符合更大規模的變更。使用廠商A的作法雖然比較快,但是一旦面對臨時的改變就會顯現出規格訂死的痛苦。

I04.設計常見問題(2)──動作責任定義錯誤

在系統裡兩個物件之間的互動動作,有的時候並不能很明顯地判知該動作要由哪一個Class提供動作方法;不管是客戶提供的需求模糊或是設計者的觀念不佳,都有可能使得動作的責任定義在錯誤的一邊,造成物件的層次被打亂而難以應付需求的改變。

比如說人與車的關係,人可以駕駛車輛,所以有Person. drive(Car)的方法,在裡面再執行Car. move()讓車去計算移動的內容。如果設計的人一時不察,把車子移動的計算寫在drive()裡再直接設定Car的相關資訊的話,雖然呼叫Person. drive(Car)這個功能同樣可運作,但是往後把Car移到其他的系統時就會發現Car根本不會move()。

動作責任的錯置在功能測試上很難測試到,即使是Unit Test裡如果測試程式由設計者寫的話,那麼他將會用自己的定義來作Unit Test而沒測到。問題將會直到某個情境下,Car被獨立出來後才會被發現,但是到那時錯誤的drive()方法已經不知散落在多少地方而難以修正。

動作的責任定義錯誤或是內容遺漏都是負責設計的人在依劇本切割時,必須戰戰競競地時時妥善加以定義。唯有所有Class都僅守本分才能讓系統更有彈性去改變。

I05.設計常見問題(3)──邏輯散落多個層次

在D02裡提到Use Case裡的邏輯應被拆分為需求邏輯與動作邏輯。需求邏輯是根據客戶的規格加以規劃應有的動作與順序,動作邏輯則是與需求無關而是以能夠完成指定動作為目的;後者的做法應是固定不動,動作的微調用設定與參數來改變,前者需去適應客戶可能有的改變,再依動作的規格找出適用的元件或專案上的特定方法。

需求邏輯與動作邏輯的分工可以讓重覆使用的元件與專案的客製化差異能同時存在並達到相輔相成的效果,其中的使用界限是非常明確的。但是一般在設計時很有可能發生需求邏輯散落在功能邏輯裡做事的問題。

客戶要在進行列印動作後在畫面顯示一個對話盒告知成功或失敗原因,在我的設計觀念裡訊息的內容與顯示方法都該在需求邏輯裡處理的,不過專案裡如果沒有人去定義層次與該在哪一層做,訊息的部分有時會不小心被寫進印表機的動作程式裡。這便是所維護產品裡的一個實例,而且兩組印表機的不同實作竟然是一組沒處理訊息而另一組有。

在訊息處理寫入印表機動作的那組實作,在不同專案裡想把訊息顯示在畫面欄位,此時必須加一個顯示方法把欄位傳進去才能在裡面顯示。但是這樣一來印表機程式就綁上了顯示的元件,要不然就是重新改寫印表機實作;改寫比較符合設計原則,但是改了以後之前使用訊息處理內建的那些專案要怎麼辦呢?

專案裡時常發生東西改來改去的狀況,而且一改就是一大片,其實那一大片都是自己造成的……。

I06.設計常見問題(4)──用重構來解決問題

"重構是解決程式裡所嗅出的壞氣味"。我是不大明白理想的重構應該針對什麼樣的範圍做什麼樣的事,但是"現在隨便寫寫能動就好,反正未來還會再重構的",卻是不少系統設計者拿來作為沒有花時間做良好設計的理由。

在我的理念裡系統是一層一層靜態物件搭配動態方法所組合起來的。從最底部的硬體架構搭上溝通橋樑、在上頭佈署元件結構再搭配定義介面、再向上有程式類別與方法呼叫,甚至連傳送的資料也有層次的不同;每個層次又有不同的參數、反應與控制動作。整個系統就像是用積木堆疊起來的巨大模型。

重構如果能侷限在局部不影響其他任何模組應該是最理想的結果,但是我所看過的重構卻是動不動就產生一個新的類別與介面,或是更改物件繼承與實作的關係。架構與物件間層次的變動會影響構築在其上的所有程式,物件繼承特性的改變也會影響內部的行為與使用的時機;這樣的改變將會造成許多與之相關的程式變得非常不穩定。

如需上述的重構應該在上頭還沒有程式構築其上時儘速進行,等到系統都快完成了才發現要變動架構或物件特性,就像民眾都把房子蓋在某片土地上後政府才說那土地是要蓋公園的,或者是像結婚典禮快開始了才發現配偶的性別不是原來我們所想的。有些改變太晚發生時,造成的影響實在是太深遠了。

I07.設計常見問題(5)──問題並不在方法論

以上提到的幾個問題時常發生在程式設計領域裡,幾乎就是系統開發失去彈性的主要原因。

問題的成因是因為設計人員對於客戶的需求只在心裡產生對應的模型(系統做到剛好滿足需求即可),只注重達成現在的功能而忽略了物件與動作的關聯及責任,以致於在客戶提出一個踩到痛處的小變更時,整個團隊改到天昏地暗。

我刻意對方法論隻字未提,因為心裡的設計層次正確時,不管用哪一種方法論來開發都能夠保有彈性。相對地,如果思考的模型只為了做出來,那麼不管用哪一種方法論,你的專案同樣會一直修改,直到不成人形再棄置一旁,然後每次的下一個專案又另起爐灶重新來過。

雖然設計的成果與方法論無關,但是OOAD的思維談的就是物件的佈置、責任與關聯,這是XP的4項價值觀和12條實踐法則裡完全沒有強調的東西。這兩年來自己在程式設計方面的成長,要歸因於接觸OOAD後有所感觸並努力思考與實踐所致。


reply to postreply to post
一個幾乎不看書的Java程式寫作員
努力考過一次SCJP但是只得到49%
理想是用XP作出符合OOAD精神的設計

從OOAD中領略人生的常理 http://ooadreason.blogspot.com
話題樹型展開
人氣 標題 作者 字數 發文時間
1944 設計常見問題 Joying 2966 2007-12-24 00:16
» JWorld@TW »  Software Design

reply to postflat modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8