Re: [分享] 用一個簡單的數學公式來幫忙設計OOP類別

看板Soft_Job作者 (LCH)時間4年前 (2020/05/20 01:37), 編輯推噓20(20推 0噓 16→)
留言36則, 21人參與, 4年前最新討論串2/2 (看更多)
先講結論: 我反對原文的結論「OOP易學難精」 就我個人到現在的感受是「難學易精」 為什麼呢? 以下分享個人看法 不管是不是OOP，其實種種軟體層面的架構手段主要都是想解決一個問題 「讓一個龐大複雜的軟體專案變得更好維護」 這又可大概分為兩個方向 1. 可擴充性 面對新需求時會不會難以改動，是不是每次加功能都要改一堆地方? 常常動一個小地方，造成其他看似無關的模組壞掉? 2. 可維護性 程式碼的邏輯是不是很好理解 會不會一個新人來看幾個禮拜還是黑人問號 每一份檔案、類別、函式 甚至到每一行程式碼的目的，是不是都足夠明確 當然，以上兩點是有相關的 這兩點的重要性，就算是剛上班幾個月的新手，也是非常容易理解 而OOP裡面的什麼pattern、什麼SOLID原則 其實說穿了也都是在讓程式更好維護和擴充而已 「難學」，是因為一開始接觸OOP，因為其概念繁多 如果沒有掌握核心思想很容易就被各種各樣的名詞給唬住 「易精」，是因為那些繁雜的概念其實都只是手段，目的是很明確易懂的 OO的核心觀念：「抽象化」 是為了讓外面的使用者只看到必要的介面 不受內部細節的改動影響 而實作者只在乎如何滿足定制好的介面 至少80%的design pattern，都是在告訴你該怎麼把抽象化做好 factory pattern 告訴你創造物件的邏輯要抽象化，外面就不必在乎實作類別的改動 strategy pattern 告訴你行為的抽象化可以用組合，達成更好的解藕並可在runtime時更換 iterator pattern 告訴你聚合類的物件可以提供一個抽象的介面 讓使用者不須關心內部時做的資料結構就可以存取所有item 另外所謂好的程式碼，怎麼會是junior沒辦法分辨？ 要是你用了很多OOP的手段，但是沒辦法輕易解釋得讓你們公司的新人聽懂這樣做好處是 什麼 那大概就是你認為的好code其實沒那麼好 沒有搞懂OOP在幹嘛，以為只是把code放在class內就算OOP 然後又看到原文這種似是而非的觀念，我是不認為會有什麼幫助 以原文提到的service object為例 的確這是一個有爭議的pattern 但要說他沒有內聚性是一件很奇怪的事情 service object其中一目的就是把domain相關的邏輯集中起來 這些邏輯本身就是緊密相關的 要用文章內提到CR值去說他沒有內聚性，真的是怎麼看怎麼怪 真的很講究OO，拆類別的時機也不應該是參數重複出現什麼的 而是現有class的職責太多吧 最後 其實軟體架構的名著Clean Architecture 就已經很豐富又很好懂了 每個階段看都有不同的感受 真的有想搞懂OOP應該去弄一本來讀讀 而不是在這邊算什麼CR值... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 58.114.218.170 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1589909867.A.FFC.html
推
05/20 01:53, 4年前 , 1F
很棒，言簡意賅
05/20 01:53, 1F
推
05/20 02:16, 4年前 , 2F
推
05/20 02:16, 2F
推
05/20 02:25, 4年前 , 3F
推，那個CR值跟本垃圾
05/20 02:25, 3F
推
05/20 03:08, 4年前 , 4F
不能同意更多了
05/20 03:08, 4F
推
05/20 08:00, 4年前 , 5F
認同本篇除了難學易精，很多設計大家都知到，但實作不
05/20 08:00, 5F
→
05/20 08:00, 4年前 , 6F
一定能寫出漂亮的架構
05/20 08:00, 6F
推
05/20 08:44, 4年前 , 7F
Clean Architecture 新手要看有點吃力，但隨著經驗增加會
05/20 08:44, 7F
→
05/20 08:45, 4年前 , 8F
越來越上手的。前陣子也試著練習了一下，還寫了個記錄
05/20 08:45, 8F
→
05/20 08:45, 4年前 , 9F
http://bit.ly/39xC9Ar 記錄的位置
05/20 08:45, 9F
推
05/20 08:48, 4年前 , 10F
https://bit.ly/3fZThCx 這是有點烙賽的 talk 版本
05/20 08:48, 10F
推
05/20 09:45, 4年前 , 11F
同意
05/20 09:45, 11F
推
05/20 09:45, 4年前 , 12F
同意 oop是用來解決問題 不是製造問題的
05/20 09:45, 12F
→
05/20 09:46, 4年前 , 13F
能解決問題的都是好OOP
05/20 09:46, 13F
推
05/20 10:09, 4年前 , 14F
如何把抽象做好比較接近SOLID，DP是延伸SOLID應用，如
05/20 10:09, 14F
→
05/20 10:09, 4年前 , 15F
何在遇到或設計初始選用適合的DP，背後包含整體架構上、
05/20 10:09, 15F
→
05/20 10:09, 4年前 , 16F
Domain Knowlege、Force等等得考量。跟單純探討把抽象
05/20 10:09, 16F
→
05/20 10:09, 4年前 , 17F
做好算不同層次的概念。
05/20 10:09, 17F
推
05/20 11:02, 4年前 , 18F
大家可能被KPI壓榨怕了，但我覺得拿來自己比較還好啦
05/20 11:02, 18F
→
05/20 11:02, 4年前 , 19F
另外推這篇觀念清楚
05/20 11:02, 19F
推
05/20 11:56, 4年前 , 20F
另外提醒SOLID和DP都是要「看情況」用的 不要以為一直用一
05/20 11:56, 20F
→
05/20 11:56, 4年前 , 21F
直爽 OOP寫過頭是會有over design的症頭的 而且這症頭還不
05/20 11:56, 21F
→
05/20 11:57, 4年前 , 22F
地方有 甚至很多知名開源專案都是一堆沒必要的design
05/20 11:57, 22F
推
05/20 12:23, 4年前 , 23F
推，好文
05/20 12:23, 23F
推
05/20 15:18, 4年前 , 24F
很同意「目標」，不要把教科書上的全部照搬就覺得是 clean
05/20 15:18, 24F
推
05/20 20:57, 4年前 , 25F
推，都是為了達成目標的手段
05/20 20:57, 25F
推
05/20 21:11, 4年前 , 26F
你的難學在指寫，精在指讀懂
05/20 21:11, 26F
推
05/20 22:49, 4年前 , 27F
借串問 那clean code需要讀嗎？
05/20 22:49, 27F
推
05/21 01:52, 4年前 , 28F
建議先讀clean code就好 clean architecture去看
05/21 01:52, 28F
→
05/21 01:53, 4年前 , 29F
Uncle Bob原始演講 後來出的書其實寫得不怎麼樣
05/21 01:53, 29F
→
05/21 06:34, 4年前 , 30F
你的精可能只是別人認為的初階而已
05/21 06:34, 30F
→
05/21 06:36, 4年前 , 31F
關於 clean code，我剛讀完覺得很不錯，現在覺得比較
05/21 06:36, 31F
→
05/21 06:36, 4年前 , 32F
像心靈雞湯
05/21 06:36, 32F
→
05/21 12:36, 4年前 , 33F
同意～說穿了所有Pattern目的都一樣
05/21 12:36, 33F
推
05/21 17:05, 4年前 , 34F
推 好文
05/21 17:05, 34F
推
05/21 19:08, 4年前 , 35F
看過高手寫的 java 程式才第一次了解到 OOP 的威力，好讀好
05/21 19:08, 35F
→
05/21 19:09, 4年前 , 36F
懂好修改
05/21 19:09, 36F
‣ 更多 as30385438 的文章
文章代碼(AID): #1Un1bh_y (Soft_Job)
‣ 更多 as30385438 的文章
文章代碼(AID): #1Un1bh_y (Soft_Job)