版主说，如果我不回 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
会死得一塌糊涂，有感....