爛**的情況，比如命名不規範、類設計不合理、分層不清晰、沒有模組化概念、**結構混亂、高度耦合等等
提高複雜**的設計和開發能力
讓讀原始碼、學框架事半功倍
為你的職場發展做鋪墊
如果你是乙個技術 leader，負責乙個專案整體的開發工作時，就需要為開發進度、開發效率和專案質量負責
當負責招聘時，如果你要考察候選人的設計能力、**能力，那設計模式相關的問題便是乙個很好的考察點
**質量高低是乙個綜合各種因素得到的結論。我們並不能通過單一的維度去評價一段**的好壞
最常用的評價標準
**不易維護：修改或者新增**需要冒著極大的引入新 bug 的風險，並且需要花費很長的時間才能完成
可讀性（readability）
如何評價一段**的可讀性
code review 是乙個很好的測驗**可讀性的手段
可擴充套件性（extensibility）
靈活性（flexibility）
簡潔性（simplicity）
可復用性（reusability）
可復用性也是乙個非常重要的**評價標準，是很多設計原則、思想、模式等所要達到的最終效果
可測試性（testability）
如何才能寫出高質量的**
設計模式可以讓我們寫出易擴充套件的**
持續重構可以時刻保持**的可維護性
設計模式是針對軟體開發中經常遇到的一些設計問題，總結出來的一套解決方案或者設計思路
程式設計規範主要解決的是**的可讀性問題
重構作為保持**質量不下降的有效手段，利用的就是物件導向、設計原則、設計模式、編碼規範這些理論
這五者都是保持或者提高**質量的方**，本質上都是服務於編寫高質量**這一件事的
設計模式之美筆記 職責鏈模式
設計模式之美 61 職責鏈模式的定義 將請求的傳送和接收解耦，讓多個接收物件都有機會處理這個請求。將這些接收物件串成一條鏈，並沿著這條鏈傳遞這個請求，直到鏈上的某個接收物件能夠處理它為止。多個處理器處理同乙個請求，處理器a完成處理後，把請求交給處理器b，處理器b處理完成後，將請求處理給c，以此類推，...
設計模式導讀
為什麼要學設計模式?低耦合，高內聚 為了解決需求變化，無法預期會來什麼新需求？所以程式要最大的可復用，新需求來時，修改盡量小，降低開發的邏輯複雜程度 邏輯簡單的小專案，就不要思考這麼多了，反而增加了開發難度，如果是乙個產品，要不停的迭代，就好好設計一下，根據自己的需要靈活變通 設計模式分為三大型別 ...
設計模式導讀
建立型 常用的有 單例模式 工廠模式 工廠方法和抽象工廠 建造者模式。不常用的有 原型模式 結構型 常用的有 模式 橋接模式 裝飾者模式 介面卡模式 不常用的有 門面模式 組合模式 享元模式 行為型 常用的有 觀察者模式 模板模式 策略模式 職責鏈模式 迭代器模式 狀態模式。不常用的有 訪問者模式 ...