設計，為了更好的應對變化

什麼是設計模式？

1.是解決某些問題的辦法

2.不是憑空想象的，是經驗的積累和總結

不可**的變化。

產品的上線只是第一步，維護和拓展才是我們花很長時間去做的。

1.當前期設計不合理，後期維護出現重大問題如何處理？立即修復、接著挖坑、推倒重做；

2.你永遠不可預知產品經理和老闆的idea，被動的接受擺布去實現各種合理、不合理的需求；

3.業務拓展，需求變更；

......

以上任何事件的發生就注定了我們要加班，有位司機說，半夜打車的不是喝酒就是搞it的。

四個階段

1.物件導向程式設計思想

什麼是物件導向？什麼是封裝、繼承和多型，以及三個特點的表現形式，基礎很重要。

2.劃分抽象與具體

如何更好的解決「變化」問題？答案是「提取抽象、隔離具體」。

什麼是「抽象」？抽象就是不變的東西，乙個資料表的操作，總會有增刪改查，把他們作為介面，這是不變的。

什麼是「具體」？具體是實際執行的，乙個資料表的增刪改查，用sqlserver、access還是oracle？可能會有變化。

我們應該依賴於抽象程式設計，而不是依賴於具體程式設計。應該把程式中的共性抽象出來，並且把具體實現的部分隔離開來，讓他們都依賴於抽象，並且互不影響。這其實就是設計。只有理解了「抽象」、「具體」、「隔離」這幾個詞兒，你才能真正理解設計模式

3.理解設計原則

單一職責原則：乙個類只負責乙個功能領域中的相應職責，或者可以定義為：就乙個類而言，應該只有乙個引起它變化的原因。

開放封閉原則：乙個軟體實體應當對擴充套件開放，對修改關閉。即軟體實體應盡量在不修改原有**的情況下進行擴充套件。

黎克特制替換法則：所有引用基類（父類）的地方必須能透明地使用其子類的物件。

依賴倒置原則：抽象不應該依賴於細節，細節應當依賴於抽象。換言之，要針對介面程式設計，而不是針對實現程式設計。

介面分離原則：使用多個專門的介面，而不使用單一的總介面，即客戶端不應該依賴那些它不需要的介面。

迪公尺特法則：乙個軟體實體應當盡可能少地與其他實體發生相互作用。

4.運用設計模式

最後才是設計模式，設計模式其實是一些工具而已。就如功夫裡的招式，沒有內功的沉澱和修煉，也只不過是空架子。

有人說幾行**的事情為什麼搞的那麼複雜？正如標題所寫設計，為了更好的應對變化。

當你設計出一套優秀**時，你會因為它不加班，因為它得到同事的讚許，因為它愛上程式設計。

附一位國外大牛的話：模式從不保證任何東西，它不能保證你一定能夠做出可復用的軟體，提高你的生產率，更不能保證世界和平，模式並不能替代人來完成軟體系統的創造，它們只不過會給那些缺乏經驗但卻具備才能和創造力的人帶來希望。