軟體工程師為什麼要學 Design Pattern? | 物件導向 | SOLID | 工程師 Nic
ฝัง
- เผยแพร่เมื่อ 5 ส.ค. 2024
- 對於設計模式的學習有多方派系持不同意見，但仔細去思考，會發現設計模式的存在是避免自己發明愚蠢的設計在已經常出現的問題上，在日新月異的科技進步下，隨著商業邏輯更加複雜，軟體工程師所遭遇到的問題也一次比一次還難
Design Pattern 的存在是幫助思考，避免不必要的協作災難，只要能懂得這點並融會貫通，職業生涯中有更多的時間去學習不同的思考方式、軟體架構以及團隊管理
成為真正的資深工程師道路上，Design Pattern 絕對是一門主修科目，你可以不完全使用，但卻不能不知道
以下是學習 Design Pattern 的推薦資源，其中包含筆記、書籍和程式碼範例
✅ 我的部落格筆記(Ruby) blog.niclin.tw/2018/11/18/%E7...
✅ 設計模式學習筆記 skyyen999.gitbooks.io/-study-...
✅ 七天學會設計模式：設計模式也可以這樣學 www.books.com.tw/products/001...
✅ 大話設計模式 JAVA 版範例: github.com/skyyen999/bigTalkD...
章節:
00:00 算我拜託你了
01:00 什麼是 Design Pattern
02:25 學習 Design Pattern 的好處
04:43 實際應用與學習方式
07:34 導入工作
喜歡影片的話！可以幫忙點個喜歡以及分享、訂閱唷！😘
━━━━━━━━━━━━━━━━
⭐ 蝦皮賣場:
⭐ instagram (生活日常): / niclin_tw
⭐ Facebook (資訊分享): / niclin.dev
⭐ Blog (技術筆記): blog.niclin.tw
⭐ Linkedin (個人履歷): / nic-lin
⭐ Github: github.com/niclin
⭐ Podcast: anchor.fm/niclin
━━━━━━━━━━━━━━━━
🌟 任何問題或合作邀約信箱: contact@niclin.tw
#designpattern #前端 #後端
10/24~10/25 我會在高雄的 MOPCON
主要擔任壓軸場的論壇與談人之一和大家分享 side project 的經營
歡迎來找我聊天以及「被採訪」😂
🔗 mopcon.org/2020/speaker/46/
程式語言讓電腦看得懂(能跑)是基本
讓人(同事)看得懂才是好工程師
我是從工作中學習後才反過頭來看design pattern 才明白原來那些道理叫design pattern 覺得你說得很對! 當一個團隊都有design pattern時 寫起來就很有共識!
其實主要問題真的是協作效率，有時候每個人都有想法，又沒有一定脈絡的時候，反而開發起來會打架，尤其團隊裡面有 2 個以上資深又很堅持己見就會這樣
@@niclin 的確..我也有遇過兩個資深以上的團隊狀況..兩個都覺得他的想法比較好，別說是coding了，有時氣氛也不好
以前在線上遊戲公司工作時，就發現如果一個專案裡只要有一個工程師在搞破壞，不遵循Desing Pattern的原則，就一定會釀出大禍。幸好我們專案的主工程師這方面的能力非常強，他總是會在底下的人亂開車的時候，及時把他們拉回正軌。所以我參與開發的遊戲，從草創到變成成品上市，都沒有出現很致命、難以找出真正問題的Bug。我自己後來負責遊戲的QA，就覺得這款遊戲的BUG都不會很難找出原因，也很容易修好。因為程式的功能都切得很細，不太會發生牽一髮動全身的狀況。
他會不會寫錯啊!!比方使用FOR迴圈結果他用DO迴圈使用DO迴圈沒有BREAK跳出迴圈然後程式無限RUN。
以前碰到一個菜鳥工程師!!!
你很棒
感謝又一部精華好片
還附連結外部資料受用很多
期待活動一切順利！
感謝支持，最近影片追很勤耶
常常看到前幾個留言是你 XD
youtube首頁突然推薦了Nic這隻影片給我，雖然我本科系不是IT相關的，但有在修程式語言的課，最近上課老師都說看我們的code看不太懂，而自己把以前寫的碼挖出來，想修改也覺得好難改，聽完這隻影片的介紹感覺獲益良多!
重點:
團隊成員要有一樣的水平理解XD
的確..我都常常跟比較資淺的工程師說..不要把所有程式都放在同一支程式.... 別人看跟維護都很痛苦, 但常常講了好久還是很多人不想改
co-work 遇過一個死不認錯型的 member …
強轉型…BLL 跟 model 都寫在 view layer…memory leak
後來勸老半天才看他寫了個 viewModel …沒有 data binding…
但厲害的是功能都有出來…
而且本人自我感覺良好…天佑 maintainer …
這影片真的很棒，邊看邊點頭XD
兩年的軟體工程師經驗，越多依賴性的編碼，會讓工程師瘋狂
難以管理也就算了，還會不知不覺養成置身事外的性格，害怕該別人的編碼
所以SOLID的D很重要
馬來西亞的軟體工程師喜歡你的影片
謝謝你的喜歡
我覺得大家都在亂寫沒一個章法的時候，大家就會開始各自只關心自己的程式，但這對團隊其實很不健康，也會讓整個開發速度沒辦法有效率的提升
所有問題都在我們公司發生 太感謝了!
我是寫 C# 也學過 23種設計模式
某些時候單一 Patten 不一定能夠符合需求，通常會多種patten 組合 或者 稍微把 patten 變形
最終是要解決問題，而不是說我用了哪個 Patten
但有時候寫了 Patten 同事看不懂又把它改壞，所以有時候不敢用，甚至以前被規定不能寫 patten
但反觀這幾年 DI 注入 是一個熱門的技術
最後我認為 Design Pattern 算是一種樣板方法，例如遇到類似的需求可以用相對應的 Patten 解決
但 Design Pattern 一定要先學，才會用
不可能突然有一天自己寫出一堆 patten，總是先有知識背景才有辦法創造XD
但你說的 Code Review 機制我很認同，今天因為太要求 clean code 精神
將太多程式 extract method，反而被主管說程式碼太碎片化，導致上下文可能看完下面忘記上面的邏輯
所以 Code Reiview 真的很重要，有時候降低自己的標準配合團隊也是一門課題
真的很棒, 以前剛踏入軟體業, 剛好公司主管有要求, 及公司文化會內訓, 一開始也都不太懂為何要.... 甚至開了好幾遍模式從最基本工廠...等等....看了好幾次就算懂也還不太懂得運用應用, 但隨著Coding年資增加, 也不斷一直偶爾再回去看一下, 慢慢得才懂的其重要性
一開始真的會不明白為什麼有這些設計方法
不過如你所說，隨著經驗的積累，重複的看見一樣場景，伴隨著更多不同的工程師風格時，就會覺得 design pattern 能夠建立基本的要求或準則，會讓協作效率好很多
最近在跟同學實作一些比較大的專案 遇到很多類似的問題。獲益良多感謝
中間那一段拔掉前端的部分真的是太好笑了，笑一笑就哭了，X
直到看了你的这个关于设计模式的视频，我想我应该对“醍醐灌顶“这个成语有更深刻的理解了。
感謝留言等級如此高的美譽
理解Design principles比去学会那23种设计模式重要的多，像Nic提到的Solid这些。
话说那23种设计模式超过一半其实都是因为Java等OO语言特性上的缺陷而产生的，在现今的环境看回当年的问题，更优雅的解决方法其实要多少有多少，所以的大家也不用太纠结在学习设计模式本身，学习设计模式并不是为了学会这些设计模式，而是去理解模式的创造者如何解决一个问题（即使一半以上的问题都是来自于OO language本身的缺陷 lol）。
老闆:Design Pattern很好! 一定要導入給客戶! 下禮拜量產!
工程師：WTF??
好寫實...
很喜歡你的講解
嘩 這個影片說明得非常好！
這集很棒很精彩, 然後找工作面試官還是問資料結構演算法, 或是leedcode給他刷起來
通常找工作都還是會挖底子，因為多數的認知是底子強學什麼都快，推敲學 design pattern 也不會慢到哪去
不過有時候遇到無腦刷題的，就不好說了 XD
上一份工作給的待遇算是不錯，但我毅然決然離開，因為你剛剛說的那些不好的設計、成員之間水平差太多，我在講git flow 對方回我eclipse....超級痛苦....開發直接連正式環境資料庫的公司，還有超級多的god class...真的受不了啊...寧願去薪水比較少的公司...因為覺得環境很重要，自己還是菜鳥，想要成長，而不是養老。
身邊前輩都說很可惜...因為給的待遇很好，讓我有時候卻會去想這樣子的離開是不是好選擇??畢竟那算是養老公司，如果不想離開，大概可以待到退休，但對於工程師一直要學習的行業，實在不想待在這樣子的環境，薪資和環境，我選擇了環境。
最後，影片講解的很棒喔！
小屁孩最容易認為版本控制就是git，不會git就是程度不好，當然，你一定不是:)
想了解一下在台湾software engineer大概薪水能开到多少？目前在新加坡，喜欢台湾，但是不知道薪水状况如何。
中華X信嗎😂
可惜了, 你應該以身作責, 把正確觀念和技術導入部門/公司.
而且您在準備的過程為了要導入教學,還會從中學習到更多, 不論是技術, 或是另一面向的準備簡報及講演, 甚至說話的架構.
讲的真好 合集工作20%code+80%设计
舉例很棒很好懂
片主口語流暢，內容豐富，受益很多，TKS!。
meta:『我學作文，不是要當程式師』，我六十多歲學程式是要和電腦友善。
SRS:【程式入綱】，工具、老師、教材三缺。
SDS:程式母語，高等物件、單元程式。
SOS:育才很重要。
厲害了大哥
說實話 我這內容對我來說 完全沒辦法接觸， 但是那些舉例說明真的是好淺顯易懂，有點屌。
學校的訓練肯定是出問題啦. 我一直有個習慣, 就是問新同事學校裡學了什麼, 似乎 Design Patterns 一般都只是輕輕帶過, 有些甚至說從未聽過...
最近就在看一本書, Adam Barr 寫的 The Problem with Software - Why Smart Engineers Write Bad Code.
書中提到坊間課程都像學法語字典, 但出來就期望學員能寫法語詩詞.
或者就是側重演算法的研究... 關於大型程序的設計, 或如何對大型程序作出修改的技巧, 就是完全沒有.
Design Patterns 推薦要看原文 GoF 版, 因為裡面有討論每個模式的優缺點以及一些變化的用法.
我們以前頂多講個幾堂Coding Standard進行團隊合作，真的沒在講Design Pattern
到後面有些連Coding Standard都不理了，基本想作就作，後面要接的人根本沒辦法維護
真的要講開發作業要正規化的時候，老闆直接跟你說一句明天就要，連測試時間根本都沒留給你
最後只能看著前人留下的無數補丁及上萬行連Format都沒有的程式擠在一團丟給你；當下結論就是直接重寫比較快.
太棒了，其实可以用到很多方面
講的超好的～支持！
感謝你的支持！！
我讀北科大 就有教，基本上整本都肯的差不多，就是加速團隊溝通，並且快速解決重複出現的問題，可惜業界用的能精通的人不多， 感謝分享 😄
推有進老師的課❤️❤️
想請問北科大學生素質如何
我是今年學測生 目標中央台科北科中字輩等 大家都說科大爛 可是我不這麼覺得 因為學測也要有52的水準才有北科
@@ting8999 先不要
北科大名校實屬牛逼
其实我在工作中也在思考如何让程序更加具备扩展性，低耦合性等等，但是往往想的很好，一旦需求变化了就出问题.没想到是design pattern这个概念。看来要好好学学了
單一職責+汽車舉例很有感
讓我想到某歐系車社團有人提過，一個小東西壞了週遭沒有關聯的零件一起壞光光，照正常的檢查步驟換了一堆零件還找不出問題根源，我想這就是每個部件沒有單一職責
Design Pattern
當經驗累積足夠多，且擦了 n 次屁股，還要預防踩雷 (大概就會有類似的技巧
不過知識傳承容易，要讓別人知道這知識是多少血淚堆積而成的，難…
如果踩在這些屍體上的同時，了解為什麼，會有很大程度的警剔
完全讲到我的坎了，哈哈
有共鳴的感覺了
我並非純資工背景的，因為合作案要開發一個大型整合的專案，中間也砍掉重練過幾次，才穩定下來，後來偶然接觸到Design Pattern整個都跪了，怎麼不早點讓我知道有此聖經，但是或許也是這份經驗讓我可以理解Design Pattern 的精髓 ，感謝你的分享
適當的使用可以來解決混亂，也會發現原來類似的問題已經有解決的公式脈絡
感謝你的留言鼓勵
我看完您的影片後!!我是過來人!!不過目前工作也不是什麼程式工程師，是在家裡寫程式的工程師賣給其他公司，主要工作都在工廠上班(非電腦行業跟程式設計，是汽修製造廠)
其實初學者要學程式語言都先從C語言開始，C語言全部學會後再學以下
Python，turbo-C，微軟的Visual，JAVA，Borland c++.....等等很容易就上手
如果初學者要從Python也可以會對於學C語言來說很輕鬆不過要走向紮實基礎還是從C語言。
看自己!!我高中的時候C語言沒有學好到後面學都很吃力!!
至於學C語言都會碰到數位邏輯還有計算機概論跟微積分(就所稱的數學)這些書本都是會碰到的。
小弟都自己寫GNU GCC(UNIX/LINUX/kali linux)
還有寫程式的邏輯要很清楚....還要會除錯和BUG。
補充!!C學完後可以再去學C++物件導向
還有自己寫出去的程式碼不要丟去雲端(我個人建議)
我都是丟在自家伺服器裡面.....不對外網路!!
NICK 你影片中提到的 同樣東西 大家命名都不一樣 真的很有感XD 可以分享一下你分類的命名規則嗎? 或是你有無GIT Repo可以參考的~
簡單、清楚、明瞭
但是，人世間很難有那麼順利的事情...
感同身受
推個
其實design pattern是個比較早期的方法，這類設計方法其實非常多，
不過如果以溝通的共同語言Ubiquitous Language而學，
GoF提的設計方法確實是很不錯的基礎。
第一個工作就遇到有用design pattern的團隊，當時用了State pattern，第二家公司有專門讀書會學習pattern，第三家公司的legacy code 出現God class, 甚至光一個 if else 就 1200行......。分別用過Java, php, C++實現過design pattern
Design pattern之後可以講一下TDD和DDD
nic真的好厉害，支持！！！
感謝支持！
我是写C#的，谢谢nic讲得非常棒，嗯，我记得要decouple王阿姨了
今天我們上課的老師，推薦我們看你的這部影片，所以我就來看了，然後發現你講的東西都還不錯，所以把你很多軟體的影片都看了XD
對於很喜歡程式的我 很支持這種頻道💪
謝謝你的支持 !!
謝謝分享
真希望硬體設計也有design pattern
Nic的频道对我这种速成班出来的工程师 真的太有用了
能幫助到你是我的榮幸
有没有考虑做design pattern讲解的视频呢？
真是很棒的影片
謝謝你的支持！
真是太剛好了吧 剛進新公司 目前正在趕上大家的進度
在學.Net Core 不過要先知道OOP跟SOLID設計原則 聽了您的講解後對於目前自學的東西有較為深刻的認知了...雖然到目前為止還是看不太懂工廠模式是什麼XD
有幫助到你是我莫大的榮幸
話說很多 pattern 我也不是每個都懂，真要全部讀起來融會貫通也是滿累的 XD
哈哈，我耦合了王阿姨
最近把一個mvc的java android app 專案改成kotlin mvvm，比較有感的是資料處理，打api部分從controller移到viewmodel，view的部分就舒服多了，剩下設定adapter等等這種畫UI的code而已
讲的非常好！我在用Javascript写Web，也在用Java学习Design Pattern
感謝你的留言鼓勵！
design pattern很大程度上是对语言features缺乏的一种弥补，假如某语言内置了该pattern为特性，那么它本就不需要design pattern。
我是反对过度学习design pattern的，很容易就过度设计，有的人写个hello world都要用上design pattern
耦合了王阿姨感覺超變態XDDD
討厭 好死相
獻上我的膝蓋
但想著想 果然還是找到對的團隊跟公司才比較有辦法成長
自己來都充滿著迷茫
選擇比努力更重要 XD
所以我才會勸很多人說，不要只看錢去選公司，不過一般人是不太理我的論點就是
@@niclin 給錢多的工作跟團隊很多強者有著高度正相關。
very well said
我寫C#,也有學設計模式。此外，影片提及使用模式可簡化程式碼，這跟我想的不同，套用模式通常會讓程式架構變複雜，但日後比較好擴充。
看到這篇留言特別有感覺XDD
跟你想的不同的部分我可以解釋，通常在 coding 到達一定水準的情況下，套用 pattern 有可能會出現更多的程式碼，但可能可以換來更好的擴充彈性
這個條件是在「一定水準情況下」
但我遇過的是，沒套用 pattern 前，程式碼就已經互相打架，寫非常多冗 code，甚至整個架構同樣或明明可以共用的程式碼卻互相以不同命名出現
結果用 pattern 帶入並且 refactor 時，才發現很多不必要的判斷是剛好順便拿掉的
才因此有了，使用 pattern 檢視設計架構，出現了「簡化程式碼」的部分
@@niclin 這樣就可以理解了 ：-）。此外，學習設計模式其實有難度，常學了卻不知道可以應用在什麼場合，是學習者常遇到的障礙。
以前初學Design pattern並實際導入到專案中，
在某個需求考慮了非常多可以擴充的情況，
都用pattern解決，
結果就發生了下面幾點狀況
1.有維護的人看到一堆interface就先放棄
2.只有5%的設計派上用場(過渡設計)
3.N個月後連自己看都忘記了...
所以後來就調整成，
目前需求確定的才用pattern設計，
其他的就遵守SOLID。
在初使用pattern時，
很容易就做出過渡設計，
寫的時候很爽，但放了100年也派不上用場.....
謝謝你的留言，很想推爆！我在工作上幾度遇到過度抽象化、使用了不需要的設計模式的程式碼，在追這種程式碼和改這種程式碼時真的很心累，很多廢話(為了抽象化而多寫的程式碼)、很難理解(因為那個設計模式不中肯，看的人會很confuse)又很難改(錯誤的設計模式加上後人疊床架屋)，真的令人痛恨。
非常推你的結論「只有需求確定的才用pattern設計」，真的！！
超想跟那些會過度抽象化的軟體工程師們說「你能預測未來嗎？能預測未來是哪個需求被提出要變更嗎？你能預測跟這一段程式碼有關的下個ticket會是什麼嗎？」「不能的話就不要提前做不需要的最佳化，請用當下現在既存的code base邏輯去思考最適合的架構。」
hello,我设计模式也学了,但是就是不会把他和spring 结合起来,能不能给点demo谢谢啦
打通我的任督二脈
最近在思考高內聚力和低耦合的問題
thanks for the video
請問Nic怎麼看最近變得很強的AI？希望能聽你談及這個話題
請問開放擴充、封閉修改 這方面關鍵字要怎麼找呢 （想找一些範例看看）
最近在公司合作的專案也應用了design pattern 的幾種模式 為了達到後續的擴充性 變成基本的功能都要想很久要動到哪幾個class 哪些資料型別不應該出現在哪些class @@寫的時候很累 可能要長遠來看才會知道它的好處吧
看這樣情況肯定是錯用了。用了設計模式，配合SRP, OCP應用，應該能夠做新增功能只需加class，對原有class只需作少改動。設計模式就是要將改動抽離獨立到某個類，令可能改動的地方不會隨處方，達至易於管理的目的。
要想很久可能是因為沒有好好解說設計模式的應用，套用的理由是什麼，預期的改動是什麼。IMHO, 針對複雜的設計模式應用，應該配合團隊的講解，或者是有文件說明。我們看設計模式這本書，也是花了很多章節去解釋的，可見只看編碼就能明白這種說法根本就不成立。
@@Tom-up9re 目前的專案是從無到有開發的，所以所謂原有的class跟新增功能的class是同步再做(就是不存在原有的class這種東西)。文件、團隊講解也是沒有的，因為也只有我跟另一位同事一起開發，專案架構是他定的，用什麼模式，原因那些他也有跟我說明， 之後我就依照這樣的需求自己做功課研究 @@
@@emilyw1507 如果有不明白的地方可以找同事討論一下。希望你有能和你一同研究討論的好同事。不怕羞說我做了很多年軟體，也陪伴過不少同事一起學習。不少同對 design patterns 應用實作過，由沒有應用設計模的編碼，一起分析維護修改遇到什麼問題，推敲應該要應用那個模式，refactor code。很多做完後會跟我說為什麼大學沒教，為什麼之前做過的公司沒用。所以我能肯定設計模式是實學，學會了而用得正確是很有益的。
@@Tom-up9re 謝謝你! 感覺你是一位很好的工作夥伴跟前輩 我會找我同事討論的，不過因為我同事自己的進度很落後XDDD 所以想找他討論又不想太打擾他 之後到一個段落會請他幫我code review
漂亮。
nic你好
最近在弄Unity，碰到了一點程式上的問題
我在每一Frame的邏輯判斷內弄了一個滑牆的判定程式碼：
▼在測試環境中從頭到尾都輸出假
if (兩個牆壁檢測區塊任意一個輸出真 且 玩家在自身Y方向的速度小於零)
{玩家在自身Y方向的速度等於零}
但問題來了，我寫的這行if不知道為什麼總會被跳過，直接執行裡面的敘述。
因為我的跳躍實作牽扯到Y方向的速度，所以我連跳都跳不起來(
應該不是被跳過，而是你有把上面的判斷式非常確定是兩個 true？
可以想辦法把判斷的東西印出來試試？
如果想做Data Scientist, 也雖要學Design Pattern嗎?
造福人群的頻道
第一次看到觀看數跟訂閱數對齊的影片
為什麼 SOLID 硬要只講三種啊
聽得正爽的說
5:53 那個是離合器 (劃錯重點逃)
看的好仔細 XDD
突然發現我以後會是一個好工程師 XD
不管大作業或小作業，我寫完都會修修改改，尤其是大作業，因為我不希望一兩個月後，連我自己都需要花時間重看自己的程式，才能看懂。
我會整理他，確保即使一兩年後，我再來看它，也能瞬間明瞭。哈哈 XD 我是不是太有自信了
我感觉，最重要的是，要先学习一下面向对象。要深入理解一下。为什么定义要定义接口
OOP / FP 也是一門學問，但無疑都是為了增進協作效率
Design Patterns 就是如何应用和综合武功的基本招式（Inheritance, Polymorphism, Abstraction, 等等）来面对与战胜不同门派的武功
沒錯，形容的很好
下一步该学Refactoring 来达到Design Patterns 😊
It’s not easy to learn design pattern in depth with dynamic language in my experience.. for web developer, try typescript and learn design pattern could be a good start, at least work for me:)
thanks for your sharing
Maybe Functional Programming has it's own design pattern?
其實rails本身設計的用意就是在降低耦合，但是當咱這些工程師使用者加入商業邏輯後一切就又都藕回來了⋯⋯
所谓工程就是这种技术和资源（资金、人力、机会）不断磨合的过程，工程师一方面要努力做好技术工作，同时也要兼顾实际的环境条件和商业需求。我认为最体现执行者水平的就在这方面了
恩..."我藕合了王阿姨"...是我想的那個藕合王阿姨嗎???
那些坑的完整SAMPLE要留下來給後人體驗，他們會更有學習動機
我很有同感 : I
感覺比念課本的老師好太多了😂😂
難!
除非是以軟體為主的公司可如此要求
但即使是軟體公司也很難要求每個人都做到
尤其台灣公司更不會給個職位專門去review別人的code
而且有的人抱著只是過客的心態 code只要能動就好 旁人也莫可奈何
只能說寫code是良心事業
我目前的公司给自己员工使用的系统里每一个模块都有自己一个god class 需要找的话需要ctrl+f 找method name，不然只会大海捞针。因为每一个god class基本超过5000行😂😂😂目前光是维护bug就花费不少时间了 还需要open-closed开发新的功能 基本是没时间重整design pattern的🙃
以前我也遇到这种代码，重写比改快很多
雖然這集不是談clean code或重構
但我還是想靠北一下我同事
他說：這些畢竟還是理論
OS：TMD人家寫code，你還在游；人家出書當神，你正在寫糞code
真正看過Design Patterns就知道滿是實用的代碼，貨真價實的設計實務。拜託！是文明人就給我去看一看書。未看懂的東西就叫理論嗎？
@@Tom-up9re 就豬隊友阿，如果只是理論，為什麼全世界工程師都在學? 難怪寫了10年Java，我使用泛型在寫共用模組，跟大家說我用的技術太深?!?!?!? Hello，只是泛型欸................
10年資歷不懂design pattern，不會重構，沒有Clean Code概念，Copy & Paste
我真得很看不起這種廢物
@@Joseph-iy4rn 同感, 我這邊也有不少, 泛型不懂, bounded generic 就更加不用說... 就是停留在 Java 1.4
你同事是人體混淆器耶
幫你們公司省一筆錢
不用去買混淆器，還不趕快感謝他XDDDD
The algorithm is working its magic.
Dependency Inversion Principle 跟我認識的好像不太一樣，仲介公司 (可以是 concrete instance 也可以是 contract interface) 也只可能只會有王阿姨一個清潔工。如果是說王阿姨有個倒立擦窗戶的功能，如果我使用了這個功能，這樣之後要換阿姨就會很麻煩，因為其他阿姨不一定會倒立擦窗戶。
如果只有王阿姨一個清潔工會這項技能，而其他阿姨不會，應該會用 Interface Segregation Principle 的概念先處理掉
把能「基本打掃」和「特技打掃」的分開來
讓打掃仲介公司裡面有分
- 基本阿姨
- 特技阿姨
這時候如果有一些人跟一些阿姨做單獨的耦合，才會用 Dependency Inversion Principle 概念去處理，看能不能透過打掃仲介解決問題
我覺得是設計模式是環環相扣的 XD
@在地上滾的工程師 Nic 我大概懂你的意思 XD 應該只是用語跟例子的差別。
ISP 又是另一個東西了，雖然它也可以套用在特殊阿姨的身上。就我所知 DIP 最大的關鍵應該是 “depend upon abstractions, NOT concretions.”。如果是說有個清潔工工會規定出來阿姨就只提供擦窗戶跟擦桌子這兩項服務，我就只能使用這兩項服務，之前我直接使用王阿姨的倒立擦窗戶或叫她去掃廁所就違反 DIP 了。仲介公司聽起來像某種 factory 或 adapter XD
我覺得設計模式在套用的時候，會因為每個人不同的見解而有些微的差距，就像你說的用語或例子的差別 XD，而這些基本的模式又會互相有一些相關
從提出問題去交流互相的想法，一直都很喜歡這種感覺，也讓我重新審視對於這個知識點的理解，舉例不夠充足或明確的部分我會再加以改進及調整
非常感謝你的留言討論
@@niclin 大大客氣了，讓我們一起往財務自由的偉大航道邁進吧
懷疑你們在開車，可是沒有證據。
我的工作經驗有遇過很多就是程式寫法風格亂七八糟的前輩 最後只能等前輩退休我再慢慢修正程式碼
喔那真的很痛苦，我後來是乾脆不等他們退休了
直接帶觀念進去，大翻修，累就在於要一直溝通
帅哥，我是一个jd，学设计模式的时候发现学不进去，我一直需要一些demo来帮助理解，太过依赖代码了；你觉得这些设计思想怎么样在不通过编码的情况下去理解呢？---不知道你能不能看懂简体字，不好意思
已知用火
JavaScript
但大多時候都在寫亂七八糟的東西，一開始也是學校沒教，後來業餘時間寫著寫著就發現這樣的問題。
現在只要發現有太多程式碼重複，或者為了要使程式碼看起來更容易理解，就會動用一些手段。
但現在才知道這叫做 Design Pattern，雖然我的作法可能歪了~
-所以能搞成這樣算走火入魔嗎?
-
pastebin.com/vEjDw6BQ
@@SpyMomiji 比起Design Pattern你应该要先试着把参数名称设好，单看Rail里就有太多不明所以的缩写与说明参数功能的comment (比方说 --> line 79 var mcat = false;//mode: catch 完全可以直接将参数命名为catchMode)。学习Design Pattern的目的是为了后续更好维护，但在之前还是要先把基本参数/function的命名学好 - 推荐看Uncle Bob的clean code了解更多
@@placeholder4842 了解，感謝
寫的語言是C# 寫到現在最大的感觸就是覺得資料跟邏輯一定要分開阿!! 不然程式耦合一定會太高
可以將它們分層，相似地，controller也跟service object設法減低耦合力
感謝早期訂閱者的回覆
辛苦的解耦都是為了要應付隨之而來的變動啊 XD
好棒的介紹! 想知道對程式新手來說，設計模式、clean code 和資結演算法，哪一項最適合先學啊? 有推薦的學習順序嗎?
Clean code， Refactor ，OOAD看完，再來看Design Pattern 會比較有感喔 ，個人學習也是依照這種方向
看多了都是淚...
應該要有廠商找我業配衛生紙...
其實框架都幫你處理好了
框架是有用設計模式，但開發的大量關於商業邏輯的編碼，難道不需要透過設計模式好好構建嗎？
好奇問一下，架構師不會在規畫的時候預防這種蠢事發生嗎？
架構師一定會, 只是..."架構師"在台灣近10年才被重視, 一堆早期或小型的軟體公司不會有這種人也不知道需要這種人
Labview 工廠模式
Design Pattern ,雲科資管的惡夢XD，以下開放跟小敏認親～
來惹, 106級畢, 60分飄過xd
大陆这边有很多不错的 design pattern （设计模式）书籍可以推荐给你们 像 以前我看过 讲得很不错
你講完後默默看了我書架上長灰塵的大話設計模式一眼
其實我在教設計模式時，還特別告訴學生盡量不要買這本，呵。
为什么？可以说一下你不推荐的理由吗？
@@RichangFoo 因為他講得太過抽象，看起來雖然像是看小說，很開心，但其實還是不會用它。對於已經會的人，也許看他可以理解（因為原本就會了），但對初學者而言，看完還是不會。
反推大話設計模式+1 推薦它的人真的有讀過嗎？
我朋友買了這本書，我看了十幾頁，對這本書吐槽質疑到不行，朋友說他也覺得這本沒寫得很好，但公司讀書會就決定了這本，他們也就拿來當大綱加減看。
這本書那時還是天瓏的人氣排行榜前幾，我真的超吐血的，寫的這麼差勁的爛書，還可以賣這麼暢銷賺大錢；現在看到上面留言，原來也有老師一樣反推這本，覺得欣慰。