※ 引述《PsMonkey (痞子军团团长)》之铭言：
: 版主说，如果我不回 po 就要浸我水桶，所以我只好... [完全误]
板主可以这样喔??
: 我不是个认真的技术者
算是实务者? XDD
: 所以 OOP 还是 OOA/D，都没有认真、完整的唸过
: 更不用说 UML 了... 棍... 那到底是哪一国语言...
UML 在台湾我不确定哪边有用比较多，
但，它有像 class diagram，都写出 class 了，
可见就是给物件导向式的程式用的，其它有些是比较泛用的。
: 同理 Design Pattern 也... [默]
C++，Java 用得比较多...对有些比较传统的语言，
不需要太多 中间层， 其实我总觉得这 Design Pattern，
多少也是因为物件导向的特性而发展的 @.@
: 在我的观点 or 学习 OOP 的过程来说
: 结构化（也许就是你说的程序导向）程式语言
: 跟 OOP 的距离并没有那么遥远
同意
: 以“封装”这个层级的角度来看，根本就一样
: 差别在于用 OOP 的程式句型，呼叫一个 method 得有主词
: 然后变量通常归属于某个主词下，变量的 scope 通常就跑不出去
算是函式有归属感，成员变量也有归属感 :QQ
: （OS：咪的... 要遵守单一责任原则，问题是...
: 切出来的这个责任到底要归谁？
: 又不能仿效政府官员踢皮球... [炸]）
切出来的就用 Design Pattern 的 Bridge 呀，Moderator 呀等等的 :QQ
反正就是再切一个物件或是接口出来 :QQ
: 接下来是我最想回的部份（OS：靠... 那上面这一大沱废话是...）
: “倒不是说OO就没有空隙，而是因为OO就算有空隙，
: 也能在系统发展的先期就显露出来。”
: 我其实不觉得，有了 OOP、发展出 OOA/D 技术
: 元件跟元件之间的组合顺畅度，在系统发展的前期就能显露出来
: 当然，以我的能力跟经验，讲这句话实在太超过了
: 只能说，我不会对这件事情这么乐观
其实我觉得说真的问题啦，都是在 使用者需求 比较多，
写到后来发现架构有问题?? 感觉上比较像是前期测试架构就没测好，
这方面我觉得和 OOP 没关系， OOAD 或许有一点关系。
: 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
: 或许相较过去，我们能够比较快乐的写出比较大的程式
: 但是，根本性的问题，依然存在
其实，我看过很大的 COBOL 程式，我觉得一开始架构好的话，
就算用 COBOL 这个一堆 GO TO 的语言，还算不会太难懂，
当然很多地方是用 Copy/Paste 硬写的 @@
但这样的程式，竟然也撑了 30 年了，也算很厉害了，
碰过一堆需求变更调整的 ( 上线之后修改 )，
也就是它是在程式一面运作，仍然一面修改的情形之下。
物件导向这方面最麻烦，很容易牵一发而动全身，
要改一个东西，要连带改一堆东西，加上现代化的架构，
有时还要改一堆 xml，让那些写 COBOL 的人，反而过来说，
不就改一点点就好了，怎么会这么麻烦。
( 当然 COBOL 麻烦的地方也是有的 )
其实一开始，物件导向刚出来时，大家都很疯物件导向，
觉得有它就能解决一切的问题，但是用久了之后，
它的问题渐渐就被发掘出来了，甚至我在看 Haskell 时，
也有人自豪得说 Haskell 的 Type 系统，比物件系统好。
而最近也看到明明在 JVM 上跑，和物件非常有关联，
但实际上又是函数语言的 clojure，
当然另一方面微软也不是省油的灯， F# 这个第一线函式语言的推出，
证实微软也不会看轻函数语言这市场，
可是我自己觉得，函数语言，也不会是没缺点的就是了。
其实我觉得像 JVM 或是微软 CLR，提供一堆让程式师选择语言，
算是比较能够符合个人喜好，又能够团队运作的模式，
毕竟，程式设计师有时需要的不只是技术或管理，
而是动力和热诚，让程式设计师本身处于自己舒适的环境之下开发，
而不要绑手绑脚，限东限西，要你乾坤大挪移也不能用，
降龙十八掌也不能用，这样出去必定功力下降，士气下滑嘛。