※ 引述《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等屬性
: 謝謝