Re: [閒聊] OOP小評

看板Soft_Job作者flyfoxy (飛狐)時間9年前 (2015/03/01 14:12)推噓6(6推 0噓 15→)

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

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 : ※ 編輯: csfgsj (61.228.26.58), 02/28/2015 21:58:49 : 推 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 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.225.162.213 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1425190347.A.7AF.html

推

snaketsai

03/01 14:24, , 1^F

03/01 14:24, 1^F

→

snaketsai

03/01 14:24, , 2^F

03/01 14:24, 2^F

推

iceonly

03/01 15:16, , 3^F

03/01 15:16, 3^F