※ 引述《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等属性
: 谢谢