※ 引述《hsnucsc (hsnugo)》之銘言： : 學習程式4年了, 一直很想學會一個好的OODesign : 之前買了很多人推的"深入淺出 物件導向分析與設計" : 但是總因為看到一半有很多疑問而打住 : 想問一下 : 1.訂定Use case和requirement非常重要嗎? : 我知道寫程式前應該要先規劃好, 但是這本書花了很多的篇幅 : 在思考, 修改它的Use case和requirement : 在很多地方, 都會讓我覺得很抽象 很重要啊。 以前常有人聽了客戶講的東西就照自己想像的跑去寫程式， 寫了幾個月寫得要死結果客戶說那不是他要的功能。 弄清楚到底該做什麼， 然後去做對的事情， 避免做了多餘的事情， 大都由這裡把關。 : 2.要怎麼知道該設計哪些class : 一個很多人建議的方法 => "名詞" : 在Usecase裡的名詞就是一個class, 他擁有的東西就是variable, 他的動作就是method 除了這個叫做 textual analysis 的方法之外， 還有 CRC analysis (你那本書附錄應該有講)， 或是把類別分成 bounary/control/entity 三大類， 再用類似 textual analysis 的原理去識別出來。 : 但是有的時候, class A該不該有class B的物件, 也是令人難決定 可以嘗試填看看 CRC card 來區分， 或者改走比較傳統的 use-case driven 路線先熟悉整個精神， 這樣你可以先學習如何找出分析期類別再把它們轉換(合併或分割)成設計期類別。 一開始就走 feature-driven 有時候對一些人來說跳太快了， 大概 run 一下傳統的做法可能比較抓得到感覺。 學習傳統做法的書我建議這本：http://tinyurl.com/4lu3zk 一方面你也可以順便學會 UML 的各種圖大概怎麼應用， 而不是空學每張圖的「語法」。 : ex: 在書中有個範例 : 要設計一個狗門, 可以用遙控器控制開關, 或因狗的聲音辨識器辨識到的聲音而開關 : 這聽起來是三個分開的class, 甚至我會覺得Recognizer應該是DogDoor所擁有的 : 但是實際上, remote需要控制DogDoor, 所以必須擁有一份DogDoor的reference : Recognizer需要控制DogDoor, 也必須擁有一份DogDoor的reference : 所以可以說, 一個class擁有哪些variable, 應該是那些東西它需要access嗎 上面這行問題的中文文法有點怪我看不太懂。 : 3.物件化程度 : 在同個例子中, 狗叫聲Bark, 有兩種作法 : 一是String bark; : 二是Bark bark; (後面還有barkList, 不過先簡化一點問題) : 如果用二, 就可以將吠聲比較交給Bark, 後面即使修改Bark的比較方法 : 也只要不需動到聲音辨識器或其他用到Bark的class : 但是這是一個我困擾很久的問題 : 我怎麼知道以後會不會修改? 參考 requirement 那個步驟得到的一些文字資訊來做判斷， 上面沒有描述到的話就當作不會。 跟物件導向搭配的開發模式大都是 iterative 而不是 waterfall， 你走完 design 還是會往回繞到 requirement 一直反覆， 你手邊的那本書可能沒有告訴你這件事， 我講的那本有。 : 如果我99%確定不會再修改, 那我直接用String bark, 程式的效率不是比較好 : 也直接可以看出他比較時做了的事情 : 如果連這樣都要物件化, 那不是有很多variable都要設計成物件 : 那像本書的第一個例子: : guitar擁有的builder, model, type等屬性, 不如也都改成物件 : 以後就可以擁有很高的彈性, 看是要怎麼比較builder, model等屬性 : 謝謝 -- Ling-hua Tseng ([email protected]) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: http://www.tinlans.org --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.160.116.1