Re: [分享] 面向對象編程從骨子裡就有問題

看板Soft_Job作者 (自立而後立人)時間11年前 (2013/02/22 12:37), 編輯推噓6(6推 0噓 40→)
留言46則, 10人參與, 最新討論串2/12 (看更多)
※ 引述《mahoihei (Alvar)》之銘言： : 早上看到一篇對個人來說很衝擊性的文章 : http://goo.gl/z4Fa3 : 為什麼說是很衝擊性,因為我自己的編程基礎由oop開始的 : 而在oop design更是我在這個領域最喜愛的地方 : 想問大家對這篇文章有什麼見解?? 鉛筆、鋼筆、原子筆，大致上都是用來寫字的， 字寫不寫得順手、好不好用，取決於他做什麼工作、作什麼事。 今天別人說鉛筆很爛不好用， 偏偏你或許剛好是習慣個用鉛筆打草稿的作家，你會理他嗎？ 重點在有沒有對你來講更好的東西，跟他有沒有解決你的問題， 不是別人怎麼批評這東西，你要看的是他的道理跟你的配合度， 如果你真的這樣想過了，你自然就會知道這東西適不適合你。 另外 OOP 並不是一種 design ，他是一種思維， Design 的部份比較多得是在你真的去實做他的那部份。 一樣是 OOP 也可以有 good design 跟 bad design ， 而且根據領域的不同，你的 good design 也可能是我的 bad design 。 -- 與其在語言世界找真理，倒不如在概念上求道。 -- 網頁上拉近距離的幫手 實現 GMail豐富應用的功臣 數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ 歡迎同好到 AJAX 板一同討論。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 175.182.230.46 ※ 編輯: TonyQ 來自: 175.182.230.46 (02/22 12:38)
推
02/22 13:04, , 1F
文章的命題是OOP「骨子」裏有問題,應該是想說OOP不該存在
02/22 13:04, 1F
→
02/22 13:13, , 2F
所以還是你覺得 OOP 對你有沒有幫助啊
02/22 13:13, 2F
→
02/22 13:13, , 3F
如果他對你有幫助，那他為什麼不該存在？
02/22 13:13, 3F
→
02/22 13:13, , 4F
我個人覺得 OOP 不是萬靈丹，但也不是一無可取。
02/22 13:13, 4F
→
02/22 13:13, , 5F
如果他要那樣批評，背後一定有什麼 context 是他假設但沒說
02/22 13:13, 5F
→
02/22 13:13, , 6F
的。像是在某些情境底下，OOP 的確賺不到好處又只是倒貼。
02/22 13:13, 6F
推
02/22 13:26, , 7F
是想捧 FP 嗎？
02/22 13:26, 7F
→
02/22 13:26, , 8F
抱歉推錯篇
02/22 13:26, 8F
→
02/22 13:27, , 9F
我理解的OOP的缺點和優點
02/22 13:27, 9F
→
02/22 13:28, , 10F
令我混亂的是為什麼,有人會說OOP是"不應該存在
02/22 13:28, 10F
→
02/22 13:31, , 11F
因為在某些情境底下 OOP 的確討不到便宜
02/22 13:31, 11F
→
02/22 13:32, , 12F
class vs mix-in 這兩種不同設計哲學，各有其優缺點與極限
02/22 13:32, 12F
→
02/22 13:32, , 13F
如果有一個人剛好他在的世界只用 mix-in 或 fp 就夠了，
02/22 13:32, 13F
→
02/22 13:33, , 14F
那他當然就會說 OOP 不應該存在。
02/22 13:33, 14F
→
02/22 13:33, , 15F
就好像很多人會說排序演算法根本不用學，call 現成的就好。
02/22 13:33, 15F
→
02/22 13:34, , 16F
因為對他們來講，他們是真的認為那沒有用卻浪費別人時間
02/22 13:34, 16F
→
02/22 13:34, , 17F
but 重點還是在於他對你有沒有用。
02/22 13:34, 17F
→
02/22 13:36, , 18F
Ruby 的作者松本行弘在其著作中，
02/22 13:36, 18F
→
02/22 13:36, , 19F
松本行弘的程式世界：成為一流程式設計師的14種思考術
02/22 13:36, 19F
→
02/22 13:36, , 20F
對於許多不同語言設計思維都有涉獵，我覺得算是就廣度跟概念
02/22 13:36, 20F
→
02/22 13:36, , 21F
上都蠻值得推薦一讀的作品。
02/22 13:36, 21F
→
02/22 13:36, , 22F
其中就有專章強調繼承 vs 多重繼承 vs mix-in
02/22 13:36, 22F
→
02/22 13:37, , 23F
但我還是那句話，工具是用來選用的，不是用來論戰的。
02/22 13:37, 23F
→
02/22 13:39, , 24F
博客來介紹 http://goo.gl/EMUL
02/22 13:39, 24F
推
02/22 13:43, , 25F
因為用的是人吧
02/22 13:43, 25F
推
02/22 13:54, , 26F
可以舉一下OOP佔不到便宜的例子嗎? 我想知道
02/22 13:54, 26F
→
02/22 14:12, , 27F
http://goo.gl/bEmRE 大概可以勉強參考一下
02/22 14:12, 27F
→
02/22 14:13, , 28F
不過真的要論述佔不到便宜，還得再多著墨些...
02/22 14:13, 28F
→
02/22 14:17, , 29F
還有 context 的誤用導致環境很髒的情況
02/22 14:17, 29F
→
02/22 14:17, , 30F
像拿 God Object 等級的設計去論述的話，OOP 顯然討不到便宜
02/22 14:17, 30F
→
02/22 14:18, , 31F
但什麼是最佳解跟是不是能夠避免錯誤設計，有些人認為這是
02/22 14:18, 31F
→
02/22 14:18, , 32F
OOP 的責任。（當然也有一票人在幹譙效率跟空間，只是那就
02/22 14:18, 32F
→
02/22 14:18, , 33F
又是另一個話題了。
02/22 14:18, 33F
→
02/22 14:19, , 34F
工具就是拿來用，你覺得不好用就不用，為了這個論戰真是..
02/22 14:19, 34F
推
02/22 15:13, , 35F
也就是說，mix-in用include的先後順序去避免鑽石繼承的問題
02/22 15:13, 35F
→
02/22 15:13, , 36F
囉?
02/22 15:13, 36F
→
02/22 15:31, , 37F
mix-in用太多的話會不知道方法從哪裡來XD
02/22 15:31, 37F
→
02/22 15:31, , 38F
是啊 還有就是 naming conflict 的問題
02/22 15:31, 38F
→
02/22 15:31, , 39F
在 JS 我們常在作 mix-in 啊，問題是還是有他的極限啊。
02/22 15:31, 39F
→
02/22 15:31, , 40F
對我來講，不過就是在不同的環境裡面選用適合的東西
02/22 15:31, 40F
→
02/22 15:32, , 41F
很多時候我會用 FP 的 concept 去寫 helper，用 OO 的概念去
02/22 15:32, 41F
推
02/22 15:34, , 42F
推。我喜歡這個說法，工具好不好用應該看遇到的問題
02/22 15:34, 42F
→
02/22 15:48, , 43F
作 core part ，就看怎麼玩...
02/22 15:48, 43F
→
02/23 01:03, , 44F
討論程式語言好壞算是老話題 XD 以激發出新想法會不錯
02/23 01:03, 44F
→
02/23 05:16, , 45F
明明要OO到什麼程度是人決定~卻老是有人反過來說OO不好...
02/23 05:16, 45F
→
02/23 05:17, , 46F
這不就像開車進小巷子嗎?明明有小車不開~偏偏要開貨車進去
02/23 05:17, 46F
‣ 更多 TonyQ 的文章
文章代碼(AID): #1H9lOWkV (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 12 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共12篇)
‣ 更多 TonyQ 的文章
文章代碼(AID): #1H9lOWkV (Soft_Job)