Re: [閒聊] OOP小評

看板Soft_Job作者gnimnek168 (Gnimnek168)時間9年前 (2015/03/01 19:40)推噓3(3推 0噓 2→)

留言5則, 5人參與討論串5/43 (看更多)

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 Hibernet 等 )，將物件與資料合而為一。 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)的關鍵架構師。 ※ 引述《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 但是我覺得那是因為他們用不到.... 03/01 12:47 -- FB 社團：軟體設計鮮思維 http://ppt.cc/~4VN -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.32.107.221 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1425210043.A.915.html

→

lachtchlee

03/01 20:46, , 1^F

03/01 20:46, 1^F

推

yauhh

03/01 21:07, , 2^F

03/01 21:07, 2^F

推

MIKEmike07

03/02 02:28, , 3^F

03/02 02:28, 3^F