版主说，如果我不回 po 就要浸我水桶，所以我只好... [完全误] 这边纯粹个人观点（OS：这句废话，整篇也是废话） 所以，先交待一下一些前提假设 我不是个认真的技术者 或着说，我根本称不上技术者，只是刚好都能硬干出东西 囧> 所以 OOP 还是 OOA/D，都没有认真、完整的念过 更不用说 UML 了... 棍... 那到底是哪一国语言... 同理 Design Pattern 也... [默] 倒是 Refactoring 的东西看起来还比较顺，是说也没怎麽再看就是了 [炸] 现在被老板下业务命令，被迫念「头先」系列的 OOAD 扫过半本... 阿？ 原来这样叫做 OOAD 不就平常做的事情吗？ coding 不都是这样吗？ [炸] 另一个前提是... 软体工法... 现在被迫得用不是那麽极端的 XP（什麽鬼） 但是基本的精神差不多，例如减少前期设计的时间、做了再说... 好了... 可以继续了...... ※ 引述《Eleganse (王建民)》之铭言： : 就我本身经验来说，OO写的系统，到後期会有越写越快的显着效果。 : 至於例子嘛，OO写的程式码，就很像一个应召站，类别与物件与成员?随传随到， : 有什麽需求，一通电话(一个小点，或一个using)立刻送达。 : 而程序导向的程式码，就很像在玩俄罗斯方块， : 你永远不知道下一步的任务是什麽， : 你永远会为了处理这些问题而大费周章。 : 倒不是程式难写， : 而是有时候会为了插入一些程序而不知道要插在哪， : 不久之後，程式架构就会跟玩俄罗斯方块一样， : 因为一些难以解决的空隙(程式逻辑上的BUG)和交货时间近逼而GAME OVER。 : 倒不是说OO就没有空隙，而是因为OO就算有空隙， : 也能在系统发展的先期就显露出来。 : 物件导向:步步为营，水到渠成 : 程序导向:兵来将挡，水来土淹 我觉得 Eleganse 版友写的太朦胧了 我只能以我的猜测去解读，解读错误的部份就请跳过（应该不妨碍阅读） 在我的观点 or 学习 OOP 的过程来说 结构化（也许就是你说的程序导向）程式语言 跟 OOP 的距离并没有那麽遥远 如同我在这个版写的那篇 #18lFux9V 文章 以「封装」这个层级的角度来看，根本就一样 差别在於用 OOP 的程式句型，呼叫一个 method 得有主词 然後变数通常归属於某个主词下，变数的 scope 通常就跑不出去 如此而已 如果这样（只在封装的等级）来看 结构化程式语言会发生的问题（如你说的「空隙」） 其实在 OO 里头一样会发生，就算会好一点，也不会好到哪里去...... （OS：咪的... 要遵守单一责任原则，问题是... 切出来的这个责任到底要归谁？ 又不能仿效政府官员踢皮球... [炸]） [异议!!] 还有「继承」跟「多型」... 「继承」其实还好，一开始的继承应该是为了避免重复的程式码 但是以现在的 OOP 的角度来看，继承其实是为了多型 无论是继承、或是继承+多型 的确「很有可能」地把元件跟元件之间的空隙给填补 或着反过来形容，元件「可能」会因此变得像 QQ 软糖一样有弹性 所以组装成成品的过程会比较顺畅一点... 这当然有个前提假设，就是 programmer 够力 我说得够力不是指 OOAD 的技术（那是後面才要扯的部份） 而是 coding 能力 不然，坦白说，即使是 Java @ Eclipse 这种组合 不知道是 Eclipse 的功能摸得不够熟还是怎样 就算有 override 的 annotation 这种程式 trace or 改起来都不太快乐 （OS：不过，比较可能的真相是→根本就是这家伙还太逊） 接下来是我最想回的部份（OS：靠... 那上面这一大沱废话是...） 「倒不是说OO就没有空隙，而是因为OO就算有空隙， 也能在系统发展的先期就显露出来。」 我其实不觉得，有了 OOP、发展出 OOA/D 技术 元件跟元件之间的组合顺畅度，在系统发展的前期就能显露出来 当然，以我的能力跟经验，讲这句话实在太超过了 只能说，我不会对这件事情这麽乐观 （即使是对照结构化程式语言） 当然，先撇开那万恶的原罪「需求变更」 （OS：还记得那九九乘法表...... lol） XP 工法可以说抓着一个囧况，因此走向极端 做出成品之後才会知道真正需要什麽 算不算前期後期，我不知道 我只知道，明明我把一个元件开发好了 但是常常却又得为了另外一个元件而修改，甚至砍掉重练 又或着，程式写出来 才发现这边要 extract method，那边要 extract interface method push 来 push 去，然後 refactoring 这种书就出来了 <囧> interface 用来用去，发现好像都是那几招 然後 design pattern 这种书就出来了 <囧> 当然，这也可以说，是 SA/SD 的功力问题 如果 SA/SD 火候十足，随时可以四人帮上身 那 refactoring 不会警告你没把握不要公布 interface 瀑布也不会消失不见....... 讲的暴力一点，如果真的在前期就能显露出来 那一卡车的 framework，除了懒惰的因素外 也没有使用的必要了，不是吗？ 重刻一个自己的 framework 能完全符合自己需求、又不用搞懂别人的东西，多好!! 我没有用结构化程式语言写过大一点的程式（至少也要超过 2K line） 可能没啥本钱讲的很肯定 我只能说，有了 OOP, OOA/D 或许相较过去，我们能够比较快乐的写出比较大的程式 但是，根本性的问题，依然存在 ===== 最近想要把用 GWT 的 project，里头 的 ui component 挂上 repaint 机制，结果原本因为 ooxx 因素抽出来 interface 会死得一塌糊涂，有感.... -- 侃侃长论鲜窒碍 首页：http://www.psmonkey.idv.tw 众目睽睽无心颤 Blog：http://ps-think.blogspot.com 茕居少聊常人事 杀头容易告白难 欢迎参观 Java 版（@ptt.cc） \囧/ --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 58.114.200.219