Re: [分享] 用一個簡單的數學公式來幫忙設計OOP類別
先講結論:
我反對原文的結論「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值...
--
很棒,言簡意賅
推
推,那個CR值跟本垃圾
不能同意更多了
認同本篇除了難學易精,很多設計大家都知到,但實作不
一定能寫出漂亮的架構
Clean Architecture 新手要看有點吃力,但隨著經驗增加會
越來越上手的。前陣子也試著練習了一下,還寫了個記錄
http://bit.ly/39xC9Ar 記錄的位置
https://bit.ly/3fZThCx 這是有點烙賽的 talk 版本
同意
同意 oop是用來解決問題 不是製造問題的
能解決問題的都是好OOP
如何把抽象做好比較接近SOLID,DP是延伸SOLID應用,如
何在遇到或設計初始選用適合的DP,背後包含整體架構上、
Domain Knowlege、Force等等得考量。跟單純探討把抽象
做好算不同層次的概念。
大家可能被KPI壓榨怕了,但我覺得拿來自己比較還好啦
另外推這篇觀念清楚
另外提醒SOLID和DP都是要「看情況」用的 不要以為一直用一
直爽 OOP寫過頭是會有over design的症頭的 而且這症頭還不
地方有 甚至很多知名開源專案都是一堆沒必要的design
推,好文
很同意「目標」,不要把教科書上的全部照搬就覺得是 clean
推,都是為了達成目標的手段
你的難學在指寫,精在指讀懂
借串問 那clean code需要讀嗎?
建議先讀clean code就好 clean architecture去看
Uncle Bob原始演講 後來出的書其實寫得不怎麼樣
你的精可能只是別人認為的初階而已
關於 clean code,我剛讀完覺得很不錯,現在覺得比較
像心靈雞湯
同意~說穿了所有Pattern目的都一樣
推 好文
看過高手寫的 java 程式才第一次了解到 OOP 的威力,好讀好
懂好修改
38
Re: [討論] 怎樣算是一個合格的junior cpp programme個人淺見,這點不見得是必要的,template 的 code 常常不好讀不好除錯 正確使用能寫出高彈性高效能的程式,但用過多維護跟閱讀起來會很痛苦 即便不用 template,日常大多數的事情都還是可以完成的, 如果是多人一起維護程式,有時為了提升可讀性,反而會避免太炫麗的 template 技巧 新人的話推薦不妨投資點時間,學習如何改善可讀性和與別人協作18
[討論] 怎樣算是一個合格的junior cpp programme諸位資工大神好,我本身是EE背景的 因為想脫離design house的生活 一直有在刷題+補充Cpp, oop 相關知識 之前有幸找到一份junior寫Cpp的工作 想了解對各位來說,有沒有一個對於qualified cpp programmer的具體標準9
Re: [請益] 比物件導向更先進的程式設計思想?依照目前看CodeReview 大部分人寫程式的方式 其實都披著OOP的皮 寫不是OOP的程式 甚至還看過很愛嘴別人的主管9
Re: [討論] 怎樣算是一個合格的junior cpp programme現在語言這麼多 你想學c++的目的是什麼 其實個人感覺你提的點以c++來說都不是重點 這年頭如果還有公司有c++的職缺 通常分兩大類 1.高效能運算5
Re: [請益] 請問程式架構和資料結構的差異安,小弟最近在複習資料結構 剛好看到了魔術方陣這題練習題 附上c#原始程式碼 你可以學我用物件導向的方式5
Re: [請益] 比物件導向更先進的程式設計思想?在討論oop fp 或任何概念之前 需要討論的是你的使用情境(context) 沒有context就只是在討論信仰 一開始沒有討論context,所以後面討論一定是到處互打,大家都覺得自己對 所以回這篇文的時候麻煩先描述想討論的contextX
Re: [請益] 比物件導向更先進的程式設計思想?國外反OOP的人不在少數 OOP 是萬惡之源 OOP is the Root of All Evil - Jeff Ward OOP 是爛東西3
Re: [請益] 比物件導向更先進的程式設計思想?幾個迷思 很多人會講C沒有OOP 實際上C有 OOP是一種paradigm 本質上還是工程師的抽象化能力 有OOP思想的人去寫C 就會有OOP的味道 腦袋裝義大利麵的寫C++還是Java C# Swift 出來都是義大利麵2
Re: [請益] 比物件導向更先進的程式設計思想?我個人主觀且偏見的覺得 OOP 不是聖杯,它只能管理一些些的複雜度,它雖好用但又沒那麼好用,它可以很容易跟其他技術結合在一起,所以起手式走oop 不見得不好,但也不用太過度期待用了能上天堂之類的 oop 就只是個工具,就像 solid 是個 guide(我也喜歡 solid,但現實世界總是不那麼美好),更別說是板上常見的 design pattern,我相信我們能從這些東西上面是可以學到一些東西,但也不用過度美化 如果真的要把程式寫好,我覺得練習寫能大量組合,無狀態,可驗證,又可高度抽象化的producedure,stateless,pipeline,wishful thinking programming 的方式會比較好,我反倒覺得這個聖杯存在很久了,只是很少人注意到 ----- Sent from JPTT on my Asus ASUS_I01WD.