關於 PTT Soft_Job 對於 OOP 的一些回應

沒想到 PTT 的 Soft_Job 看版有人在聊 OOP 的觀念,忍不住作了一些回應。

  1. 早期把物件化的分析/設計思維歸為 OOA/OOD (Object-Oriented Analysis/Design);實現物件化思維的程式語言則稱之為 OOP (OO Programming)。
  2. 實現 OO 思維主要有兩個機制:介面 (interface)、多型 (polymorphism)。包括 .NET/Java 等主流語言,早已支持 OOP,甚至連 php/python 等原來屬於 script-based 的程式語言,也朝向 OO 化的實現機制。
  3. 從 OOP 的角度來看到物件化的設計思維是不妥的;原因在於絕大數開發人員並不知道 Why OO Thinking!其實採用 OO 設計化思維是必然會增加開發成本的。因為它並非為了解決某一局部的邏輯性問題,而是考量全局,從系統整體來看待「變動 (Change)」的議題,進而提出如何擁抱改變 (embrace changing)的解決方案。
  4. 再則從實作上,OO 化的特徵是分散式的 (因為基於類別 (class)的責任分派 (responsibility assign)原則)。所以為了實現 OOP 的分散式架構,程式碼必然大量分散於各類別內,如此會造成實作與偵錯的難度;因而一個必要的配套措施:TDD (Test Driven Development),測試先行是一定要養成的好習慣。
  5. 越是大型變動頻繁、高度維護,或者期待包裝為產品,增加其再利用性價值的系統,採以 OO 的設計/實現 (當然,前提要有這樣實在技能的軟體架構師/Developer)才能感受到其好處:每一次只改變一點點;每一次的變動可以侷限在可控制的變動範圍內。
  6. OO 的特徵是將 程序/資料 封裝至某一類別內,其實在抽象層次,程序稱之為「行為 (behavior)」、資料稱之為「屬性 (attribute)」,兩者均為物件必然會有的特徵 (features),是非常自然不致分離的。但因現實仍沒有一種有效的機制能把物件的狀態 (state)儲存起來,所以實作技術上是把物件與資料分離,資料儲存於資料庫系統內、待執行期間 (run-time)才透過如 OR Mapping (如 .NET ER Framework、Java Hibernate 等),將物件與資料合而為一。
  7. 實業界很有趣的一個現象:重視 MIS (Management Infomation System)系統的公司,幾採以資料導向的開發模式;重視 Web 框架如網路行銷公司,大都採以程序導向的開發模式。至於所謂的 OO 化,實現的程度其實還蠻微小的。
  8. 順待提下重構 (refactor)的觀念:重構是屬於事後 (Coding 後)的設計,一般與事前 (Coding 前,如典型的 SA/SD)設計可能存在著 3:7 或 4:6 (事前:事後)的比重。而且往往寫完程式才是另一段故事的開始:持續重構 (continous refactoring)。
  9. 重構的要件:不會影響到已經上線系統的所有功能。 衡量重構的指標:每一個 method 不會超過 10 行、最長不得超過 20 行。
  10. 如今重視 Web 相關技術、快速實現商業創意的年代,其實已少人有人談及 OO 更遑論具體實踐了。西元2000年以前,包括 UML 三大師 (Booch、Rumbaugh、Jacobson)、Martin Fowler (重構一書即為他的著作)、Kent Beck (XP/Agile 的始祖)、Bob (Clean Code 作者)均為支持物件思維的軟體大家。國外除了這些大師外,實現 OO 的專家其實也不多,一般是會落在如開發底層框架 (如 .NET Framework)的關鍵架構師。
  11. ※ 引述《flyfoxy (飛狐)》之銘言:
    : OOP不只是從GUI的角度出發,我以OpenCV這個第三方lib做為例子
    : 我個人從OpenCV1.0開始使用到現在
    : 他去年有了3.0beta版
    : 我看到他從最早1.0版幾乎是c code,沒有使用class/namespace..etc
    : 好在只是DLL function呼叫,c code 其實也還好,
    : 如果有去trace過JM1.6版的c code,那真的令人暈頭轉向
    : 又沒有UML的圖,function這個call那個,回傳值全部用
    : pointer,到了另外一個地方又是另一個pointer名稱
    : 但它是原先那個pointer傳過來的,這真的是純c code的痛苦。
    : OpenCV2.0版開始他就更有結構化,使用class/namespace進行封裝
    : 也建立了線上document分類分好
    : 想要找特徵學習還是影像處理,一目瞭然。
    : OOP絕對有他的缺點,比如看一個class發現他可能繼承於別人
    : 然後就要再去看上層的class,有見樹不見林的感覺。
    : 但如果document做的好,有類似Start UML的圖表,其實架構是很清楚的。
    : 或者說過多的繼承會導致class十分龐大臃腫
    : 或者說資料和程序難以分開 導致十分難trace
    : 我也曾經在如何抽離介面和演算法之間徬徨
    : 但其實這些問題不是不能克服的
    : 微軟的Doc/View模式某種程度上就已經幫了你一點忙
    : 甚至其實是coding習慣的問題,因為一開始架構就沒有寫清楚
    : 或是時間不夠流程和資料就混成一堆,程式能動就好,
    : 或是因為後續的需求變更使得class間的耦合性變得更複雜
    : 所以當你程式越寫越大,你就越早面臨「重構」這件事情
    : 上述的問題透過「重構」其實都可以得到解決,
    : 只是大家應該都沒時間「重構」,
    : 或者說因為「重構」不會讓你薪水變多,只是事情變多,
    : 但我覺得應該要推廣一個觀念
    : 如果一個軟體想要「永續經營」,「重構」這件事情是必要的
    : 除非你寫了一隻程式,以後都不會去改動它,
    : 都沒有維護/增加功能的問題。
    : ※ 引述《csfgsj (Lazy bone)》之銘言:
    : : From護法兄
    : : 有些人愛用oop,或許真的有一些理由
    : : 從Gui的角度來出發,也許真的是一個蠻契合的Paradigm
    : : 但一個Paradigm適用範圍畢竟有限
    : : 出了這個範圍,若還是要硬套,那就是自找麻煩
    : : 就我的觀點來看,OOP裡的確有不少討厭、自找麻煩的東西存在
    : : 什麼是理工學生的思維模式?以及
    : : 十數載在學校的學習,是在作什麼?
    : : 能不能用幾個簡單的字來詮釋它?
    : : 我的理解就這四個字:
    : : 定性、定量
    : : 即對世間的事物,學習培養對其定性或定量之能力
    : : 什麼物理、化學、數學等理工學科都一樣,都是在作這樣的事,沒有例外
    : : 而且能否對事物作定性定量,也就成了評量對事務是否瞭解的普世標準
    : : 漸漸地,它成為所有理工學生的思維基礎
    : : 處理陌生事物前,要先對它作有效的定性定量
    : : 這樣的作法也就理所當然,成為標準程序
    : : 反過來說,一個遲遲無法定性定量的事物
    : : 就會成為理工科學生的困擾,甚至惡夢
    : : 尤其是在無法逃脫非要處理它的情況下
    : : 幾乎所有的軟體,都是由許多不同的軟體元件疊加起來的
    : : 一個軟體工程師很可能只作其中的一部分
    : : 其它的部分不是現成的,就是別人作的
    : : 有很大的一部分,工程師的工作只是在整合這些元件
    : : 我的問題是
    : : 工程師在整合這些元件之前,能對它們作有效的定性定量嗎?
    : : 不管是C++還是JAVA以及其他的OOP程式語言
    : : 都有所謂Class的語法,並且大量的被使用
    : : Class就是資料加程序的集合體
    : : 有人說這是個好東西
    : : 以我的觀點,它確是個萬惡之源
    : : 資料是資料,程序是程序
    : : 兩者是性質完全不相同的東西
    : : 當你刻意將兩個性質完全不相同的東西併在一起成為一個東西之後
    : : 其結果就是
    : : 你創造了一個無法被有效定性定量的東西
    : : 大量的無法定性定量的東西被創造出來,並且存在於程式之中
    : : 程式會呈現什麼景象?亞馬遜叢林
    : : 在亞馬遜叢林,一切都變的隱誨,似明未明
    : : 基於本能,人在這時候往往採取保守小心的策略
    : : 以免不小心,那邊冒出一隻大蟒蛇,把你一口吃掉
    : : 隱誨、保守小心,也就是侷限的開始,愚化的淺勢開端
    : : 由其是經驗不夠的時候,很容易就此走不出來
    : : 因此
    : : "工程師的缺德行為:叫朋友去學C++"
    : : → bibo9901: 不同意, 並不是把 data 和 function 分開就看得清楚 02/28 20:58
    : : → bibo9901: linus 指的 "substandard programmer" 應該就是這種吧 02/28 21:03
    : : → rodion: 是否搞錯OOP的正確用法? OOP不代表任何東西都要用OOP 02/28 21:23
    : : → lachtchlee: 笑話一則 02/28 21:41
    : : → csfgsj: rodion觀念正確,但很多人不是 02/28 21:50
    : : → csfgsj: 給lachtchlee:大家一起哈哈笑吧! 02/28 21:51
    : : 推 typepeter: 只想問閣下成就如何...XD 我認識Googler也沒像你這樣說 02/28 23:02
    : : → typepeter: 看似說了什麼 卻全篇心得文 未有實際上作法 02/28 23:04
    : : → typepeter: 你說堆DomainKnowledge, so? 除了聽起來很酷,然後? 02/28 23:05
    : : → typepeter: 好像是發功程式就會出現一樣 有無具體作法? 02/28 23:06
    : : → typepeter: 所謂D.K.要如何精鍊 如何判斷要不要用框架 有無具體? 02/28 23:09
    : : 推 iceonly: 平平都是寫code,工作環境不同也有不同的心得,也許他的 03/01 01:20
    : : → iceonly: 業務是個與OO無緣的世界,那也沒啥好批評的;反對OO的論點 03/01 01:23
    : : → iceonly: 也很多,原PO說的也是常見的一種 03/01 01:24
    : : 推 iceonly: 只是OO/DP/各種framework都只是為了降低維護成本的一種工 03/01 01:40
    : : → iceonly: 具而已,不用那些或許達的到但是用了會簡單很多 03/01 01:41
    : : → iceonly: 某種功能在短時間內純手刻就能實作/新增是很厲害沒錯,但 03/01 01:42
    : : → iceonly: 使用上述工具就能在同樣時間內達到同樣效果時帶給老闆的 03/01 01:43
    : : → iceonly: 效益是一樣的話那好像也還好 03/01 01:44
    : : → iceonly: 感覺像是練過心算的在嘲笑用計算機的人一樣 03/01 01:46
    : : → anguso: 我認識的 Googler 似乎都懶得對這種文回應... 03/01 06:02
    : : → y3k: 我不相信沒有OOP能有效率地完成什麼大型專案 有些script工程 03/01 12:46
    : : → y3k: 師喜歡批評OOP 但是我覺得那是因為他們用不到....

文章導覽

   

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。