※ 引述《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，提供一堆讓程式師選擇語言，
算是比較能夠符合個人喜好，又能夠團隊運作的模式，
畢竟，程式設計師有時需要的不只是技術或管理，
而是動力和熱誠，讓程式設計師本身處於自己舒適的環境之下開發，
而不要綁手綁腳，限東限西，要你乾坤大挪移也不能用，
降龍十八掌也不能用，這樣出去必定功力下降，士氣下滑嘛。