Re: 今天被問倒了...
版主說，如果我不回 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
討論串 (同標題文章)
OOAD 近期熱門文章
PTT數位生活區 即時熱門文章
