什么是設計模式博投？
設計模式就是前人總結的代碼設計的模型绸贡，就像武俠里面的武功的招式，套路毅哗。
為什么需要設計模式疤隆？
我平時代碼敲的也沒有問題啊虑绵，功能也完成了叉跛，線上跑的很健康
1、統(tǒng)一編程風格
實現(xiàn)功能蒸殿，這屬于硬編碼，沒有什么技巧鸣峭，形成不了模式宏所，只能說是個copyer，復制人摊溶。大部分代碼都是cv的爬骤。不能稱得上工程師，你敲的代碼不能成為工程級別的項目莫换∠夹可能你寫的代碼只能你自己看得懂，如果你的命名不規(guī)范的化拉岁，就會形成自己的一套代碼風格坷剧。
2、易維護喊暖，行內統(tǒng)一語言
如果你使用設計模式惫企，大家的代碼風格統(tǒng)一了，大家都有了共識陵叽，理解代碼的結構也很輕松狞尔，不過這里有個大前提，就是你的團隊巩掺，都懂設計模式偏序。
3、代碼更優(yōu)雅
設計模式胖替，讓你的代碼更優(yōu)雅研儒，比如建造者模式
HttpClient.builder().url("<http://aliserver/api/user/query>")
.method(Method.GET)
.parameter(Map.of("uuid", "432231", "key", "di2da2ddsa3s"))
.build();
4豫缨、可擴展性強，輕松應對多變需求
設計模式殉摔，可以讓代碼寫的復用性好州胳，可擴展性強。說白了逸月，就是面對多變的需求栓撞，你可以改動很少的代碼就能適應新需求，就像汽車的部件一樣碗硬，代碼功能塊就像汽車部件了瓤湘，拆拆裝裝，就產生新的新特的汽車恩尾。這樣的代碼弛说，老板喜歡，因為節(jié)省開發(fā)成本翰意，減少人力木人；深受同行吹捧，因為這已經成為工匠打磨的作品冀偶。
怎么使用設計模式
從我學習設計模式的經驗醒第，記住概念，記住類圖 进鸠，很容易忘記稠曼，容易混淆各個設計模式。后來發(fā)現(xiàn)客年，記住設計模式的本質是很重要的霞幅，讓圍繞這個本質，再去看這些設計模式量瓜，比較容易吸收點司恳。
設計模式的目標：讓代碼，維護成本低绍傲，面對多變需求抵赢，可擴展性強.
設計模式的本質：面向抽象，隔離實現(xiàn)
用白話解釋就是唧取，設計模式都是抽象類铅鲤，接口來組織代碼關系，實現(xiàn)層都是被隱藏的枫弟，也就是隱藏細節(jié)邢享，面向抽象層。
那么為什么要面向抽象淡诗，隔離實現(xiàn)呢骇塘？
因為抽象是穩(wěn)定的,實現(xiàn)層是具體的細節(jié)伊履，是多變的。
舉個例子款违，用戶登錄注冊這樣的需求唐瀑，抽象出來，就是用戶服務：userService插爹，有l(wèi)ogin（）哄辣，register（）。然后我們提測赠尾，測試經過數(shù)天的功能測試力穗，回歸測試，生產驗證气嫁，功能發(fā)布成功当窗，
這是不變的方法吧。如果要來了一個微信登錄這些細節(jié)的時候寸宵，那么user這個類就不穩(wěn)定了崖面。所以我們設計成abstract userService，wxUserService梯影，qqUserService巫员。
可以做到面對多變需求，動態(tài)擴展光酣，不需要修改原有的類，避免了維護原有類脉课，測試原有功能的工作量救军。
然后為了“面向抽象，隔離實現(xiàn)”這個目標倘零，先人提出了設計原則
我們開發(fā)一個訂單系統(tǒng)的項目唱遭，經過需求評審，代碼實現(xiàn)呈驶，單元測試拷泽，功能測試，線上運行袖瞻，投入了很多的人力成本司致，才交出了stabale穩(wěn)定的代碼。
現(xiàn)在需要添加一個功能，作為老板，或者管理人員橙垢，我們希望不要修改原有功能模塊的代碼忌堂，這樣增加了回歸已有功能的工作量，也增加了線上原有功能影響的風險膳汪，所以期望只在原有基礎擴展現(xiàn)有功能容燕。
這里桥狡，就得提到拄轻，開發(fā)程序要符合開閉原則颅围，做到不修改，只擴展恨搓。
要做到開閉原則院促，就得引出設計原則：單一職責，我們定義的類的功能邊界要明確奶卓，職責清晰一疯，這樣面對多變的需求變動的可能性就小，比如下單功能夺姑，orderService只負責訂單的創(chuàng)建訂單墩邀，修改訂單功能，如果還參雜著的物流信息的功能盏浙，下次如果物流功能變更眉睹，就會牽扯到訂單功能。
上面我們提到了废膘，抽象是穩(wěn)定的竹海，實現(xiàn)是多變的，所以引出了依賴倒置的原則丐黄，我們定義的類與類之間斋配，是通過抽象層產生關系，抽象層不依賴實現(xiàn)類灌闺，實現(xiàn)類要依賴抽象層艰争，體現(xiàn)了“面向抽象，隔離實現(xiàn)”
還有接口隔離原則桂对，接口的實現(xiàn)類甩卓，不要實現(xiàn)跟自己無關的抽象方法，類的繼承也要做到盡可能少的繼承與自己無關的方法蕉斜，這樣做也是為了減少上層的變動影響了下層逾柿。
在程序開發(fā)中，類與類之間肯定會產生關系宅此，就難免產生耦合机错，類之間關系越復雜，牽涉到某功能變動父腕，就會影響毡熏，不符合開閉原則，所以我們約定類與類之間盡可能少的產生依賴關系侣诵，只與自己直接關系的類有依賴關系痢法，這也就是迪米特法則狱窘，也就是最小知道原則，
類的繼承财搁，是強耦合的東西蘸炸，給程序帶入了侵入型，基類的方法尖奔，被子類繼承搭儒，如果繼承的方法發(fā)生變更，子類功能都會受影響提茁，所以我們約定了 子類繼承基類淹禾，只能繼承原有方法，新增新的功能方法茴扁，不得重寫父類的功能方法铃岔，這就是里氏替換原則：出現(xiàn)基類的地方，子類能替換峭火。
合成復用原則：少用繼承毁习，多用合成，依賴關系卖丸，為了減少耦合的可能性纺且。
總結
遵守了上面提到了設計原則，我們的代碼健壯性更強稍浆，可擴展性也更好载碌，減少了代碼的出錯率。
設計模式衅枫，就是基于上述的7大原則嫁艇，形成的一套招式，其中比較典型的就是橋梁模式为鳄。
