我一開始, 并不是很看重設(shè)計(jì)模式, 認(rèn)為設(shè)計(jì)模式?jīng)]太多作用, 在移動(dòng)開發(fā)的時(shí)候, 用處不大. 直到后來, 開發(fā)的項(xiàng)目變多, 遇到了很多的問題. 才逐步理解了設(shè)計(jì)模式.?
當(dāng)時(shí)也不是特意學(xué)習(xí)的設(shè)計(jì)模式, 而是在面試中被問及到, 工作中使用過哪些, 當(dāng)時(shí)都回答不上來, 事后回顧這些問題, 都用了哪些呢, 慢慢發(fā)現(xiàn), 自己在使用設(shè)計(jì)模式, 但是不知道使用的是設(shè)計(jì)模式.
我理解的設(shè)計(jì)模式, 是為解決問題, 提供的很多思路, 當(dāng)遇到一個(gè)情景時(shí), 應(yīng)該如何著手編寫代碼, 可以更好的擴(kuò)展, 降低代碼間的關(guān)聯(lián)呢. 設(shè)計(jì)模式提供了合適的方案.
我是一名iOS開發(fā)者. 當(dāng)初開發(fā)智能硬件時(shí), 面臨iOS7, iOS8的系統(tǒng)相冊(cè)方法更新, 以及硬件上的圖片資源和手機(jī)沙盒中的圖片, 同時(shí)有4種不同方式的圖片資源, 需要再App內(nèi)使用, 總不能寫A, B, C, D4個(gè)類, 在程序中, 每個(gè)使用圖片的地方, 就判斷一下吧, 那樣的話, 代碼會(huì)有很多if else. 于是, 就用 <適配器模式> 將每個(gè)圖片的使用方式, 封裝成同樣的. 再繼承自同一個(gè)父類. 這樣, 使用多態(tài)和封裝, 就在程序中, 使用最小的改動(dòng), 使得所有地方可以統(tǒng)一的使用圖片資源. 如果以后iOS15, 又變更了圖片庫(kù), 程序內(nèi)也不用太多改變. 只需 "修改" 適配器, 既可以繼續(xù)通用. 在設(shè)計(jì)模式的引導(dǎo)下, "修改" 適配器, 也不一定是去修改適配器的代碼. 可以用 繼承, 組合, 多態(tài)等方式, 去更新迭代.
這就是設(shè)計(jì)模式帶來的便利之處.
裝飾者模式，把A類傳入B類碱妆，B類跟A類實(shí)現(xiàn)同樣的接口(很像)舆驶，但是B比A更豐富. 在B類中, 跟A類同名的方法, 就直接調(diào)用A類
外觀模式柑晒，內(nèi)部創(chuàng)建A数苫，B眷茁，C多個(gè)類筷凤，在某個(gè)方法中耸携，調(diào)用他們中的方法, 進(jìn)行組合棵癣。
橋接模式，跟裝飾者很像夺衍。但不是為了擴(kuò)展狈谊，為了替換
組合模式，自己沟沙，自己2對(duì)象河劝，自己3對(duì)象。全部封裝在自己內(nèi)矛紫。二叉樹的樣子
模板模式赎瞎，重寫抽象類某方法，實(shí)現(xiàn)替換
單例模式, ?全局只有一個(gè), 共享同一個(gè)
原型模式, ?父類提供公共方法, 子類覆寫父類方法. 即多態(tài)
適配器模式, 將不同的類的屬性方法, 通過適配器, 封裝成一樣的.
代理模式, 傳遞某對(duì)象,?通過協(xié)議, 可以使用該對(duì)象的特定方法.
工廠模式, ?在工廠類中使用, ?某超類的子類, 子類自己重寫了父類中會(huì)被使用的方法,?
