**
it職場的小菜經常有這樣的疑問：
為什麼乙個相似的功能，大牛一會兒就搞定，然後悠閒地品著下午茶逛**；而自己加班加點搞到天亮還做不完。
為什麼使用者提出需求變更後，大牛只需瀟灑地敲敲鍵盤，改改配置；而自己將**改了又改，刪了又建，幾乎暈厥，最後只能推翻重來。
為什麼大牛寫完的程式測試上線後，幾乎完美執行，使用者無懈可擊；而自己的程式bug重重，改好乙個卻又引出另乙個，按下葫蘆浮起瓢，幾近崩潰。
為什麼同樣是程式設計師，大牛工資1w，而自己只能拿區區的3k？
大牛顯然知道一些小菜所不知道的秘密，這秘密又是什麼呢？
這個秘密就是設計模式。設計模式（design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、**設計經驗的總結。使用設計模式是為了可重用**、讓**更容易被他人理解、保證**可靠性。設計模式使**編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。只有精通了設計模式，才敢說真正理解了軟體工程。可以說，設計模式是每乙個架構師所必備的技能之一。作為乙個物件導向設計程式設計師，只有精通了設計模式，才能完成自身價值從3k到1w的飛躍，才能擺脫碼奴的命運，成為乙個真正的軟體工程師。
提到設計模式，不得不感謝gof（gang of four，四人組），他們2023年出版的《設計模式:可復用物件導向軟體的基礎
1.單例模式 2.工廠方法模式 3.抽象工廠模式 4.模版方法模式 5.建造者模式 6.**模式 7.原型模式 8.中介者模式
9.命令模式 10.責任鏈模式 11.裝飾模式 12.策略模式 13.介面卡模式 14.迭代器模式 15.組合模式 16.觀察者模式
17.門面模式 18.備忘錄模式 19.訪問者模式 20.狀態模式 21.直譯器模式 22.享元模式 23.橋梁模式
那麼如此多的設計模式又是從何而來呢？《易經》有云：「易有太極，是生兩儀，兩儀生四象，四象生八卦」，意思就是說世界萬物皆有起源。而設計模式的起源是物件導向程式設計思想，是物件導向設計的精髓——抽象。物件導向通過類和物件來實現抽象，實現時產生了物件導向的三個重要機制：封裝、繼承、多型。正是這三個機制衍生出了各種各樣的設計模式。在物件導向軟體設計的發展過程中，除了《設計模式》一書中提到的23中設計模式之外，新的設計模式仍然不斷出現。
從面向過程到物件導向是軟體設計誕生以來的邁出的最偉大的一步，物件導向程式設計成功解決了面向過程軟體程式設計的低效率問題，並且徹底改變了人們的程式設計思維，為軟體設計揭開了新的篇章。然而，要實現物件導向設計，徹底擺脫面向過程設計思維，並不僅僅是只要使用了一門物件導向的程式語言就能夠達到的。使用物件導向設計，可以設計出優秀的軟體，同樣也可以設計出糟糕的軟體。只有遵循一些特定的原則，才能設計出復用性高靈活性好的軟體來。
在運用物件導向的思想進行軟體設計時，需要遵循的原則一共有6個，他們是：
1.單一職責原則（single responsibility principle）
2.黎克特制替換原則（liskov substitution principle）
3.依賴倒置原則（dependence inversion principle）
4.介面隔離原則（inte***ce segregation principle）
5.迪公尺特法則（low of demeter）
6.開閉原則（open close principle）
在軟體設計的過程中，只要我們盡量遵循以上六條設計原則，設計出來的軟體一定會是乙個優秀的軟體，它必定足夠健壯、足夠穩定，並以極大的靈活性來迎接隨時而來的需求變更等因素。當完全明白這六個原則的含義時，小菜便完成了走向大牛的蛻變。
我知道四人幫的《設計模式:可復用物件導向軟體的基礎》是一本標準書，倒不如先看看這部大部頭《head first設計模式(中文版)
相關文件：國外**評出對程式設計師最具影響的書籍清單
邁出從3K到1W的重要一步 掌握設計模式
it職場的小菜經常有這樣的疑問 為什麼乙個相似的功能，大牛一會兒就搞定，然後悠閒地品著下午茶逛 而自己加班加點搞到天亮還做不完。為什麼使用者提出需求變更後，大牛只需瀟灑地敲敲鍵盤，改改配置 而自己將 改了又改，刪了又建，幾乎暈厥，最後只能推翻重來。為什麼大牛寫完的程式測試上線後，幾乎完美執行，使用者...
邁出從3K到1W的重要一步 掌握設計模式
it職場的小菜經常有這樣的疑問 為什麼乙個相似的功能，大牛一會兒就搞定，然後悠閒地品著下午茶逛 而自己加班加點搞到天亮還做不完。為什麼使用者提出需求變更後，大牛只需瀟灑地敲敲鍵盤，改改配置 而自己將 改了又改，刪了又建，幾乎暈厥，最後只能推翻重來。為什麼大牛寫完的程式測試上線後，幾乎完美執行，使用者...
邁出從3K到1W的重要一步 掌握設計模式
it職場的小菜經常有這樣的疑問 為什麼乙個相似的功能，大牛一會兒就搞定，然後悠閒地品著下午茶逛 而自己加班加點搞到天亮還做不完。為什麼使用者提出需求變更後，大牛只需瀟灑地敲敲鍵盤，改改配置 而自己將 改了又改，刪了又建，幾乎暈厥，最後只能推翻重來。為什麼大牛寫完的程式測試上線後，幾乎完美執行，使用者...