Re: [請益] 如何學習物件導向?

看板Soft_Job作者 (仙人異路)時間10年前 (2015/08/13 13:07), 10年前編輯推噓8(8推 0噓 88→)
留言96則, 14人參與, 最新討論串4/9 (看更多)
※ 引述《jetswayss (小犬)》之銘言： : 1. : OO是design的問題 怎麼去設計OO program : 基本上OO就什麼也不是,程式怎麼寫都可以 : 但為什麼我們需要OO呢? : 因為沒有人有辦法管理各式各樣的錯綜複雜的code : " 所以有人想要用SOP，也就是框架來處理管理軟體 雖然它有時候可以省一些事，只是框架必定受限 好的框架設計也就算了，碰到爛的框架可以讓您天天罵髒話 : 我們希望藉由帶入物件的理念進入軟體世界 稱之為「物件」其實只是一種商業宣傳手段 從定性的角度來看，這種定位既錯誤也無價值 : " : 物件 會有自己的屬性 外加上 我們給予的限制 框架的特徵出現了 : 會使得程式更好管控 擴充 維護... 這部分真的是Bull shit，做過案子就知道 : 屬性指的是 介面 => 掌控 物件行為規範 框架的特徵 : 類別、繼承、多載、 : 多型、介面、委派、抽像 : " : 這些都算是OO的基礎 這些都是框架實作的手段、語法 : 為什麼要繼承 這是從一個硬框架開始建構程式的手段 : 3. : 設計模式的部分 這是一堆框架的集合，想法也要依據框架的規範 : 基本上OO是需要一段時間去適應學習的 : 注重於 analysis 和 design (OOAD) : 這部分才是OO的精華與難處 這是框架適應：思維、作業方式自我閹割的過程 : 軟體的世界就只是一堆trade-off而已 : 這樣方便 這樣有利 就這樣做 : 所以在不同的特性的產品 往往使用不同的開發流程、設計方式、程式語言 : 千萬不要讓OO變成唯一方案 這是真的，除非有好處 要不然為何要自宮去練葵花寶典 : 要知道優弊 自己決定你的設計 神功重要還是雞雞重要，自己要想清楚 -- ※ 編輯: csfgsj (210.71.206.217), 08/13/2015 13:15:19
→
08/13 13:18, , 1F
又是一篇廢文
08/13 13:18, 1F
→
08/13 13:21, , 2F
優! "物件導向"只是一個宗教術語,怎麼樣生出好維護高品
08/13 13:21, 2F
→
08/13 13:23, , 3F
質的code才是重點,如果有更好的設計方法,何必一定要OO?
08/13 13:23, 3F
→
08/13 13:24, , 4F
只要作出高品質的code,用函數編程也可以
08/13 13:24, 4F
推
08/13 13:34, , 5F
如果這麼簡單就有好的設計方法,那就不會有OO出現了zzz
08/13 13:34, 5F
→
08/13 13:34, , 6F
我們也不需要看design pattern了 對吧 XD
08/13 13:34, 6F
→
08/13 13:35, , 7F
為什麼會有MVC 會有物件導向 會出現framework 是不是應該
08/13 13:35, 7F
→
08/13 13:35, , 8F
回到需求面來思考?
08/13 13:35, 8F
→
08/13 13:36, , 9F
幾個人開發的程式跟幾百人開發的程式,方式絕對不同
08/13 13:36, 9F
→
08/13 13:36, , 10F
生命週期短跟生命週期長的專案,開發方式也會不同
08/13 13:36, 10F
→
08/13 13:37, , 11F
原作者只是要問如何學物件導向,針對這點來回應吧 不要扯遠
08/13 13:37, 11F
→
08/13 13:38, , 12F
自己學生時代直接寫個幾十萬行的應用程式 就自然體會
08/13 13:38, 12F
→
08/13 13:39, , 13F
很多事情了. 剩下的就是網路多看別人怎麼設計.
08/13 13:39, 13F
→
08/13 13:39, , 14F
物件導向本來就是個懂概念很簡單,寫得好需要長年練習的東西
08/13 13:39, 14F
→
08/13 13:50, , 15F
物件導向或許在10幾年前是個很好的解決方案吧....
08/13 13:50, 15F
→
08/13 13:52, , 16F
直到現在也還是阿 不然幹嘛一堆公司面試要問你OO的概念
08/13 13:52, 16F
→
08/13 13:56, , 17F
現在進入平行化/大數據/IoT 的世紀,用OO開發是不是最好
08/13 13:56, 17F
→
08/13 13:56, , 18F
的解已經不一定囉
08/13 13:56, 18F
推
08/13 13:57, , 19F
其實...面對 scale out 的 grid computing 和平性運
08/13 13:57, 19F
→
08/13 13:57, , 20F
算，就會開始有 anti-oo 和 function orient 的議題
08/13 13:57, 20F
→
08/13 13:57, , 21F
了，就更NoSQL和 反正規化設計一樣，本來就不是ㄧ藥
08/13 13:57, 21F
→
08/13 13:57, , 22F
治百病，但看到有人這樣一面倒地反對，也只是另一個
08/13 13:57, 22F
→
08/13 13:57, , 23F
不切實際的極端罷了
08/13 13:57, 23F
→
08/13 13:58, , 24F
無論如何,函數編程/mapreduce 概念已經興起了
08/13 13:58, 24F
→
08/13 14:00, , 25F
所以重點是,OO已經不是唯一解,打code不要定侷限某一種
08/13 14:00, 25F
→
08/13 14:00, , 26F
還是老話一句 看需求決定該怎麼做.
08/13 14:00, 26F
→
08/13 14:00, , 27F
生出你的同事也看的懂且容易維護的code才是最該思考的
08/13 14:00, 27F
→
08/13 14:02, , 28F
不然用了OO,結果變數名取個_001,_002這種的,只會....
08/13 14:02, 28F
→
08/13 14:04, , 29F
很熟OO的人會採用這種命名嗎 別開玩笑了好嗎 = =
08/13 14:04, 29F
→
08/13 14:07, , 30F
請專注重點,舉命名的例子只是印證打code界裡還是有白痴
08/13 14:07, 30F
→
08/13 14:13, , 31F
這種白痴就算不是用OO也不會變天才好嗎
08/13 14:13, 31F
→
08/13 14:16, , 32F
幫這篇護航那位大概不知道這位大濕覺得複製貼上最好
08/13 14:16, 32F
→
08/13 14:16, , 33F
遇到重複性高的代碼怎麼辦? 通通複製貼上就好
08/13 14:16, 33F
→
08/13 14:19, , 34F
推薦可以估狗一下, ORM 在彈性方面的問題
08/13 14:19, 34F
→
08/13 14:19, , 35F
"只看"推文的話，說的其實有道理.....
08/13 14:19, 35F
→
08/13 14:19, , 36F
ex 估狗 "ORM flexibility"
08/13 14:19, 36F
→
08/13 14:20, , 37F
像是, 痾..., "花花" 的這一篇有一些探討
08/13 14:20, 37F
→
08/13 14:20, , 38F
08/13 14:20, 38F
→
08/13 14:20, , 39F
只是想說 OO 確實不 "總是" "只有" 好處
08/13 14:20, 39F
→
08/13 14:21, , 40F
有些狀況真的寧可不 OO
08/13 14:21, 40F
→
08/13 14:21, , 41F
shadow0326大大,我知道這位大師何許人也,但我不算護航
08/13 14:21, 41F
→
08/13 14:21, , 42F
吧,我的重點是不該侷限某一種開發思維
08/13 14:21, 42F
→
08/13 14:23, , 43F
我同意OO有缺點阿 我有些時候寫純C是完全不考慮OO的 看場合
08/13 14:23, 43F
→
08/13 14:24, , 44F
但是這樣討論下去 似乎偏離了原作者想問的問題了XD
08/13 14:24, 44F
→
08/13 14:27, , 45F
我反而覺德原作者最先該想的就是這樣的"問題",而不是
08/13 14:27, 45F
→
08/13 14:28, , 46F
被前輩噹一噹就覺得"不能再逃避"了,侷限在某一種開發
08/13 14:28, 46F
→
08/13 14:28, , 47F
不去接觸新東西新技術新時代,才算是逃避拉
08/13 14:28, 47F
→
08/13 14:30, , 48F
尤其台灣的"資深前輩",大部分都是10幾年前的絕招現在
08/13 14:30, 48F
→
08/13 14:31, , 49F
還在用的"資深主管",一堆連git都沒聽過的老灰仔
08/13 14:31, 49F
→
08/13 14:33, , 50F
職場上是你去配合環境而不是環境來配合你 別害人了好嗎XD
08/13 14:33, 50F
→
08/13 14:33, , 51F
那種看到樓主沒有用OO就噹人的人,就像看到年輕人沒有把
08/13 14:33, 51F
→
08/13 14:34, , 52F
changelog打在程式碼的最開頭就說"你寫程式怎麼都不紀
08/13 14:34, 52F
→
08/13 14:35, , 53F
錄一下改了啥??",拜託版本控制觀念已經快20年了
08/13 14:35, 53F
推
08/13 14:43, , 54F
leolarrel，樓主沒你想的這麼前衛，他支持的沒用OO，拿你
08/13 14:43, 54F
→
08/13 14:44, , 55F
例子來講，就是，「changelog寫在程式開頭就好，用什麼git
08/13 14:44, 55F
→
08/13 14:44, , 56F
，版本控管系統爛死了。」這樣的感覺。
08/13 14:44, 56F
→
08/13 14:47, , 57F
恩,請問你說的樓主是dnabossking嗎?
08/13 14:47, 57F
→
08/13 14:48, , 58F
當然如果他的程式用OO比沒用OO好,那自然該改,只要不要
08/13 14:48, 58F
推
08/13 14:49, , 59F
csfgsj，你看一下他之前發文就知道了。他應該很資深。
08/13 14:49, 59F
→
08/13 14:49, , 60F
是肯定用OO是可以產出好品質好維護的code即可
08/13 14:49, 60F
→
08/13 14:50, , 61F
我記得 csfgsj 之前就貼了不少反對OO的文章，你可以看看他
08/13 14:50, 61F
→
08/13 14:50, , 62F
的論點。
08/13 14:50, 62F
→
08/13 14:51, , 63F
csfgsj這個神人我也挺...的,另,只要OO適合你的案子,沒
08/13 14:51, 63F
→
08/13 14:52, , 64F
有理由不用
08/13 14:52, 64F
→
08/13 14:53, , 65F
不要向那種老灰仔一樣什麼都是OO最好就行了
08/13 14:53, 65F
推
08/13 14:53, , 66F
dnabossking只是個公司新人 你們要他去跟公司前輩吵要不要
08/13 14:53, 66F
→
08/13 14:53, , 67F
OO 要不要怎樣 不覺得是在害人嗎....= =
08/13 14:53, 67F
→
08/13 14:54, , 68F
在討論工具合理性之前 在新公司就先黑掉了 何必這樣
08/13 14:54, 68F
推
08/13 14:57, , 69F
leolarrel遇到的老灰仔的類型跟我完全不一樣耶 XD
08/13 14:57, 69F
→
08/13 14:58, , 70F
我遇到的，是完完全全把java當成c在寫，幾乎沒用class，把
08/13 14:58, 70F
→
08/13 14:58, , 71F
可能我比較衰,遇到的資深前輩80%都是食古不化,唉
08/13 14:58, 71F
→
08/13 14:58, , 72F
jsp當成php用。完全沒物件導向，用物件導向寫，還會把程式
08/13 14:58, 72F
→
08/13 14:59, , 73F
碼拆出來到jsp中，說「我幫你把程式碼改的好一點」
08/13 14:59, 73F
→
08/13 15:00, , 74F
LaPass說的那種人我也不能認同,該什麼情況就該用適合的
08/13 15:00, 74F
→
08/13 15:01, , 75F
思維與方法
08/13 15:01, 75F
→
08/13 15:01, , 76F
結果，我在一段常常剪下貼上的一段程式碼中發現有sql注入
08/13 15:01, 76F
→
08/13 15:01, , 77F
他問我該怎麼改，我回答不知道，因為那個段落我估計在整個
08/13 15:01, 77F
→
08/13 15:02, , 78F
系統一兩萬頁jsp中，我估計有大概有幾百到幾千頁都有用到
08/13 15:02, 78F
→
08/13 15:03, , 79F
然後又不能用搜尋取代，因為每個片段都有點點不一樣。
08/13 15:03, 79F
→
08/13 15:03, , 80F
因為他沒有OO結果那個sql inject bug散佈各處,對吧?
08/13 15:03, 80F
→
08/13 15:03, , 81F
還好我不寫網頁,不會遇到他,不然....
08/13 15:03, 81F
→
08/13 15:04, , 82F
有OO不代表不會遇到bug，但是許多狀況只要改一個地方，其
08/13 15:04, 82F
→
08/13 15:05, , 83F
他用到同一片段程式碼的部份就都能一起修好了。
08/13 15:05, 83F
→
08/13 15:07, , 84F
LaPass,沒錯
08/13 15:07, 84F
→
08/13 16:07, , 85F
改一個Bug能修一個禮拜為什麼要用一天，Code只有我知道去
08/13 16:07, 85F
→
08/13 16:07, , 86F
那些地方改，增加自己的不可替代性
08/13 16:07, 86F
→
08/13 16:07, , 87F
有些人大概就是這種想法吧
08/13 16:07, 87F
→
08/13 17:47, , 88F
好的OO確實方便管控和維護啊...怎會BS
08/13 17:47, 88F
→
08/13 21:01, , 89F
感謝各位大大寶貴的意見
08/13 21:01, 89F
推
08/14 00:24, , 90F
這篇還不錯
08/14 00:24, 90F
→
08/14 07:40, , 91F
OO和Functional不衝突，可以並存的不是嗎？
08/14 07:40, 91F
推
08/14 18:34, , 92F
嚴格的 functional programming 有
08/14 18:34, 92F
→
08/14 18:35, , 93F
referential transparency 也就是沒有state 沒有side
08/14 18:35, 93F
→
08/14 18:36, , 94F
effect 所以這和OO不相容 現在把兩者結合的程式 其實
08/14 18:36, 94F
→
08/14 18:36, , 95F
就是犧牲了finctional lang的referential transparen
08/14 18:36, 95F
→
08/14 18:37, , 96F
cy特性 還使老話一句 任何東西都有tradeoff
08/14 18:37, 96F
‣ 更多 csfgsj 的文章
文章代碼(AID): #1Lp2Oim3 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 4 之 9 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共9篇)
‣ 更多 csfgsj 的文章
文章代碼(AID): #1Lp2Oim3 (Soft_Job)