※ 引述《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