最糟糕的物件導向分析設計文件

最近 review 一份有如天書的「物件導向設計文件」,不禁想到《物件導向分析設計與應用》書中有這麼一段:
「最糟糕的物件導向分析設計文件,是將每一個類別各寫成一份文件,然後在每份文件裡面描述該類別的所有方法。這種作法會產生很多沒用的文件,沒人會看、也沒人會信賴這樣的文件,而且它也無法呈現跨越單一類別的重要架構議題,也就是類別與物件之間──尤其是元件之間──的合作情形。比較好的作法是,將這些高階結構用 UML 圖形表現,然後提示開發人員可以到哪裡找到某些重要類別的詳細說明。」 (摘自第七章,p.322)

我碰到的這份 SD 文件,不是把一個類別寫成一份文件,而是把一堆類別的方法、屬性清單都集中在同一份文件。不過,效果是差不多的--都可以令嘗試理解該文件的人產生頭暈、挫折、憤怒等不適症狀。

整份文件 90% 都是類似下圖這樣的內容(我把原本的類別名稱、屬性等內容改掉了,僅保留其格式與寫法):



整份 SD 文件提供的唯一線索,就是類別的屬性和方法清單--連一張基本的類別圖都沒有,當然更別提循序圖、物件圖、狀態圖了。從這些表格式的描述當中,恐怕連柯南也猜不出各類別之間的關聯,以及它們是如何完成一項功能或 use case。

進一步來看,類別「EntClassInventry_產品」及其屬性約略透露兩件事。首先,這是個 entity class,命名方式為類別名稱前面加上 "EntClass",另外還看到以 CtClass 開頭的類別(這裡沒貼上來),應該就是 control class。那麼,若沒意外,在某個地方應該會出現以 BndClass 開頭的 boundary class 吧。這看起來好像是說:只要每一支程式都遵循 ECB pattern 就可以宣稱是物件導向程式了。

其次,這些類別規格極可能是由工具產生出來的。之所以如此推測,一方面是類別與屬性名稱均呈現特定(不具親和力)的規則,另一方面,都已經細到 SD 文件了,類別名稱裡面卻還有中文字,看來應該是在系統分析時使用中文來命名類別(這在高階分析時還 OK),而在進入系統設計時,由工具依命名規則所產生出來的制式類別名稱。雖然 .NET 程式的類別、變數名稱可以用中文命名(我只做了簡單的測試,不確定是否有其他副作用),但個人還是反對這麼做--寫程式時得經常切換輸入法的中英模式,不嫌麻煩嗎?

也許,將來我們可以看到從系統分析、系統設計、到程式設計的過程中,所有的類別、屬性、方法都使用中文命名,如此一來,大家就不用再為了命名時該用哪個英文單字而傷腦筋了,既方便又直覺。從此以後,我們終於可以擺脫英文了......是這樣嗎?

我想,我大概有點老古板吧!我始終無法想像一個宛如 coding machine 的開發人員寫出來的程式碼會有多好的品質。

另一個我不能接受的地方,是屬性名稱直接取用資料庫的欄位名稱,而沒有做任何大小寫命名規則的對應轉換處理,因而產生 PROD_NAME 這樣的屬性名稱。這不僅違反了 .NET 一般的命名原則,寫程式的時候也很不方便:本來寫程式時敲大寫鍵的次數並不多,現在恐怕要考慮 Caps Lock 要不要都開著了(此系統是採用 .NET 平台,但即使是 Java 也不適合用這種全大寫加底線的命名方式)。

就我自己的觀察,剛才提到的那些問題,只不過是物件導向技術運用不當所產生的結果罷了。問題的真正根源,恐怕是主事者對物件導向技術的了解太膚淺,而在經驗不足的情況下,不僅低估了軟體系統的複雜度,同時又對自身的技術過於托大,認為可發展出一套以工具為中心的自動化 OOAD 標準開發流程,幻想著所有開發人員皆可隨時替換的「人力池」美夢。

我知道有些一起工作的同事和朋友偶爾會到我的部落格逛逛,這帖文或許又要得罪人。很抱歉這麼說,但是,(OOAD 的)球~真的不是這麼踢滴!

3 則留言:

  1. 大大的文章..都很受用哦..XD..謝謝..

    只是..會很想知道..如果像這樣子的東西..應該修改成怎麼樣..才是大大建議的方式咧??

    回覆刪除
  2. 呃...三言兩語很難回答完整。我可以建議參考這本書嗎:
    《物件導向分析設計與應用 第三版》
    裡面有一些範例可以參考(順便打書啦 :P)。

    回覆刪除
  3. XD..謝謝..

    只是看到網路上很多文章..會寫出缺失的地方..就沒有怎麼改比較好的建議..好奇問的而已啦..XD..3Q~~~

    回覆刪除

技術提供:Blogger.
回頂端⬆️