? ? 當(dāng)我們剛開始接觸業(yè)務(wù)的時候，也許會遇到這么一個問題彤恶。隨著代碼的需求的增加钞钙，或者業(yè)務(wù)的不完善鳄橘，需要增加（修改）代碼声离，來滿足需求，對于沒有什么經(jīng)驗的程序員（比如說我）來說瘫怜，常常采用頭疼醫(yī)頭术徊，腳痛醫(yī)腳的方式來解決問題，在原有的代碼基礎(chǔ)上直接修改代碼鲸湃。這就會遇到一些問題赠涮。
? ? 首先，原有的代碼是好久以前的暗挑，對于我來說笋除，可能一個月前的代碼就看不太懂了，在原有的基礎(chǔ)上該或許會出現(xiàn)新的問題炸裆。其次垃它，新加的代碼，會是我們代碼變得更加亂糟糟烹看，不利于下一次維護(hù)国拇。那有人會問，面向?qū)ο蟀」呤猓瑸槭裁匆婚_始就將一些方法寫為父類酱吝，然后新的需求可以做為接口，使得要調(diào)用該方法子類實現(xiàn)該接口土思。但是务热，如果有整個項目有一半的接口要使用該接口，另一半不需要呢己儒。崎岂。。址愿。
一该镣、什么是設(shè)計模式
? ? 說說我們軟件設(shè)計的幾個個原則：
? ? 1.一個軟件不可避免的會面對一個問題：change，如果不改變响谓，就只能等著淘汰损合。那么，我們就要在程序設(shè)計之初娘纷，先要明確哪些是將來基本不變的嫁审，哪些是將來可能會改變的，還有哪些是將會頻繁變動的赖晶，那么我在設(shè)計時為將來的代碼就會預(yù)留接口律适，而把頻繁變動的獨立開來辐烂，下次就改這一部分就行了，這樣系統(tǒng)就會變的更有彈性捂贿。
? ? 2.針對接口編程纠修，而不是實現(xiàn)編程。聽起來很拗口厂僧，我自己也不是很理解扣草，簡單的說說我的理解吧。如一個子類颜屠，它的行為一般是繼承（實現(xiàn)）父類（接口）辰妙，那么，它的行為就是在該類編譯階段被定死了甫窟，類里面的覆蓋或者父類的實現(xiàn)將會是該類對該行為的唯一實現(xiàn)密浑。但是，有時候粗井，我們可以把這種行為抽象為一個接口尔破，在父類中作為一個屬性，那么我們就可以按照需求調(diào)用該接口的不同實現(xiàn)背传。這樣也可以更好的代碼復(fù)用呆瞻，不用因為不同行為，要重寫方法径玖，導(dǎo)致有多個不同類痴脾。
? ? 3.多用組合少用繼承。這和二一脈相承梳星，是從is-a到has-a的轉(zhuǎn)變赞赖。因為組合能給代碼提供較大的彈性，可以靈活的改變冤灾。
? ? 說到這里前域，我們也就引出了第一種設(shè)計模式：策略模式。那么韵吨，我們差不多也可以對其下一個定義：
????設(shè)計模式（Design pattern）代表了最佳的實踐匿垄，通常被有經(jīng)驗的面向?qū)ο蟮能浖_發(fā)人員所采用。設(shè)計模式是軟件開發(fā)人員在軟件開發(fā)過程中面臨的一般問題的解決方案归粉。這些解決方案是眾多軟件開發(fā)人員經(jīng)過相當(dāng)長的一段時間的試驗和錯誤總結(jié)出來的椿疗。
二、設(shè)計模式存在的意義
? ? 這里看下head first設(shè)計模式中的幾個場景
? ? 如圖糠悼，其實兩個人點的東西是一樣的届榄，但FIO和廚師之間有共享詞匯（也就是菜譜），使得其點餐更加便捷倔喂。設(shè)計模式也是這樣铝条，它是開發(fā)人員溝通過程中的共享詞匯靖苇，方便開發(fā)，使得開發(fā)人員的思考架構(gòu)的層次上身到模式層面班缰，如下圖
