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

[csfgsj (仙人異路)]

※ 引述《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
→ Deltaguita: 又是一篇廢文
→ leolarrel: 優! "物件導向"只是一個宗教術語,怎麼樣生出好維護高品
→ leolarrel: 質的code才是重點,如果有更好的設計方法,何必一定要OO?
→ leolarrel: 只要作出高品質的code,用函數編程也可以
推 hidog: 如果這麼簡單就有好的設計方法,那就不會有OO出現了zzz
→ hidog: 我們也不需要看design pattern了 對吧 XD
→ hidog: 為什麼會有MVC 會有物件導向 會出現framework 是不是應該
→ hidog: 回到需求面來思考?
→ hidog: 幾個人開發的程式跟幾百人開發的程式,方式絕對不同
→ hidog: 生命週期短跟生命週期長的專案,開發方式也會不同
→ hidog: 原作者只是要問如何學物件導向,針對這點來回應吧 不要扯遠
→ hidog: 自己學生時代直接寫個幾十萬行的應用程式 就自然體會
→ hidog: 很多事情了. 剩下的就是網路多看別人怎麼設計.
→ hidog: 物件導向本來就是個懂概念很簡單,寫得好需要長年練習的東西
→ leolarrel: 物件導向或許在10幾年前是個很好的解決方案吧....
→ hidog: 直到現在也還是阿 不然幹嘛一堆公司面試要問你OO的概念
→ leolarrel: 現在進入平行化/大數據/IoT 的世紀,用OO開發是不是最好
→ leolarrel: 的解已經不一定囉
推 tomtang0406: 其實...面對 scale out 的 grid computing 和平性運
→ tomtang0406: 算，就會開始有 anti-oo 和 function orient 的議題
→ tomtang0406: 了，就更NoSQL和 反正規化設計一樣，本來就不是ㄧ藥
→ tomtang0406: 治百病，但看到有人這樣一面倒地反對，也只是另一個
→ tomtang0406: 不切實際的極端罷了
→ leolarrel: 無論如何,函數編程/mapreduce 概念已經興起了
→ leolarrel: 所以重點是,OO已經不是唯一解,打code不要定侷限某一種
→ hidog: 還是老話一句 看需求決定該怎麼做.
→ leolarrel: 生出你的同事也看的懂且容易維護的code才是最該思考的
→ leolarrel: 不然用了OO,結果變數名取個_001,_002這種的,只會....
→ hidog: 很熟OO的人會採用這種命名嗎 別開玩笑了好嗎 = =
→ leolarrel: 請專注重點,舉命名的例子只是印證打code界裡還是有白痴
→ adks3489: 這種白痴就算不是用OO也不會變天才好嗎
→ shadow0326: 幫這篇護航那位大概不知道這位大濕覺得複製貼上最好
→ shadow0326: 遇到重複性高的代碼怎麼辦? 通通複製貼上就好
→ lovdkkkk: 推薦可以估狗一下, ORM 在彈性方面的問題
→ a47135: "只看"推文的話，說的其實有道理.....
→ lovdkkkk: ex 估狗 "ORM flexibility"
→ lovdkkkk: 像是, 痾..., "花花" 的這一篇有一些探討
→ lovdkkkk: http://martinfowler.com/bliki/OrmHate.html
→ lovdkkkk: 只是想說 OO 確實不 "總是" "只有" 好處
→ lovdkkkk: 有些狀況真的寧可不 OO
→ leolarrel: shadow0326大大,我知道這位大師何許人也,但我不算護航
→ leolarrel: 吧,我的重點是不該侷限某一種開發思維
→ hidog: 我同意OO有缺點阿 我有些時候寫純C是完全不考慮OO的 看場合
→ hidog: 但是這樣討論下去 似乎偏離了原作者想問的問題了XD
→ leolarrel: 我反而覺德原作者最先該想的就是這樣的"問題",而不是
→ leolarrel: 被前輩噹一噹就覺得"不能再逃避"了,侷限在某一種開發
→ leolarrel: 不去接觸新東西新技術新時代,才算是逃避拉
→ leolarrel: 尤其台灣的"資深前輩",大部分都是10幾年前的絕招現在
→ leolarrel: 還在用的"資深主管",一堆連git都沒聽過的老灰仔
→ hidog: 職場上是你去配合環境而不是環境來配合你 別害人了好嗎XD
→ leolarrel: 那種看到樓主沒有用OO就噹人的人,就像看到年輕人沒有把
→ leolarrel: changelog打在程式碼的最開頭就說"你寫程式怎麼都不紀
→ leolarrel: 錄一下改了啥??",拜託版本控制觀念已經快20年了
推 LaPass: leolarrel，樓主沒你想的這麼前衛，他支持的沒用OO，拿你
→ LaPass: 例子來講，就是，「changelog寫在程式開頭就好，用什麼git
→ LaPass: ，版本控管系統爛死了。」這樣的感覺。
→ leolarrel: 恩,請問你說的樓主是dnabossking嗎?
→ leolarrel: 當然如果他的程式用OO比沒用OO好,那自然該改,只要不要
推 LaPass: csfgsj，你看一下他之前發文就知道了。他應該很資深。
→ leolarrel: 是肯定用OO是可以產出好品質好維護的code即可
→ LaPass: 我記得 csfgsj 之前就貼了不少反對OO的文章，你可以看看他
→ LaPass: 的論點。
→ leolarrel: csfgsj這個神人我也挺...的,另,只要OO適合你的案子,沒
→ leolarrel: 有理由不用
→ leolarrel: 不要向那種老灰仔一樣什麼都是OO最好就行了
推 hidog: dnabossking只是個公司新人 你們要他去跟公司前輩吵要不要
→ hidog: OO 要不要怎樣 不覺得是在害人嗎....= =
→ hidog: 在討論工具合理性之前 在新公司就先黑掉了 何必這樣
推 LaPass: leolarrel遇到的老灰仔的類型跟我完全不一樣耶 XD
→ LaPass: 我遇到的，是完完全全把java當成c在寫，幾乎沒用class，把
→ leolarrel: 可能我比較衰,遇到的資深前輩80%都是食古不化,唉
→ LaPass: jsp當成php用。完全沒物件導向，用物件導向寫，還會把程式
→ LaPass: 碼拆出來到jsp中，說「我幫你把程式碼改的好一點」
→ leolarrel: LaPass說的那種人我也不能認同,該什麼情況就該用適合的
→ leolarrel: 思維與方法
→ LaPass: 結果，我在一段常常剪下貼上的一段程式碼中發現有sql注入
→ LaPass: 他問我該怎麼改，我回答不知道，因為那個段落我估計在整個
→ LaPass: 系統一兩萬頁jsp中，我估計有大概有幾百到幾千頁都有用到
→ LaPass: 然後又不能用搜尋取代，因為每個片段都有點點不一樣。
→ leolarrel: 因為他沒有OO結果那個sql inject bug散佈各處,對吧?
→ leolarrel: 還好我不寫網頁,不會遇到他,不然....
→ LaPass: 有OO不代表不會遇到bug，但是許多狀況只要改一個地方，其
→ LaPass: 他用到同一片段程式碼的部份就都能一起修好了。
→ leolarrel: LaPass,沒錯
→ a47135: 改一個Bug能修一個禮拜為什麼要用一天，Code只有我知道去
→ a47135: 那些地方改，增加自己的不可替代性
→ a47135: 有些人大概就是這種想法吧
→ Ekmund: 好的OO確實方便管控和維護啊...怎會BS
→ dnabossking: 感謝各位大大寶貴的意見
推 locklose: 這篇還不錯
→ Wush978: OO和Functional不衝突，可以並存的不是嗎？
推 recorriendo: 嚴格的 functional programming 有
→ recorriendo: referential transparency 也就是沒有state 沒有side
→ recorriendo: effect 所以這和OO不相容 現在把兩者結合的程式 其實
→ recorriendo: 就是犧牲了finctional lang的referential transparen
→ recorriendo: cy特性  還使老話一句 任何東西都有tradeoff