版主說，如果我不回 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