設計模式概述
說起設計模式，我想不得不說的是 GOF的23種設計模式。
《Design Patterns: Elements of Reusable Object-Oriented Software》(設計模式：可重用面向?qū)ο筌浖囊?（即《設計模式》一書），由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 合著（Addison-Wesley，1995）。這幾位作者常被稱為"四人組（Gang of Four）"。
雖然 GOF是基于Java語言提出的，但是同樣是面向?qū)ο笳Z言的OC/Swift 在設計之時都是有借鑒意義的。
設計模式（Design pattern）是一套被反復使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設計經(jīng)驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。只有精通了設計模式，才敢說真正理解了軟件工程。可以說，設計模式是每一個架構師所必備的技能之一。
設計模式的起源是面向?qū)ο蟪绦蛟O計思想，是面向?qū)ο笤O計的精髓——抽象。面向?qū)ο笸ㄟ^類和對象來實現(xiàn)抽象，實現(xiàn)時產(chǎn)生了面向?qū)ο蟮娜齻€重要機制：封裝、繼承、多態(tài)。正是這三個機制衍生出了各種各樣的設計模式。
只有精通了設計模式，才敢說真正理解了軟件工程?？梢哉f，設計模式是每一個架構師所必備的技能之一。
個人總結：架構設計就是給軟件系統(tǒng)搭一個架子，這個架子最后是鋼筋結構（抗腐蝕性）而不是木頭結構。模塊的粒度不能太小，也不能太大，要大小適中，而且要高聚合低耦合，最終的效果就像一塊塊的磚利用簡單的鏈接沿著架子可以搭建成型。 對修改關閉對擴展打開，不過擴展也屬于修改吧，修改的話盡量在小模塊中修改，能多小就多小，因為大的模塊中邏輯復雜，你改了一點點就可能影響整個大模塊的正常運行（因為有可能手誤，動了不該動的東西，對大模塊引入了風險）。
iOS 中的 21 種設計模式
大話設計模式之oc實現(xiàn)23種模式
如何避免過度設計
設計模式是為了封裝變化，讓各個模塊可以獨立變化。精準地使用設計模式的前提是你能夠精準的預測需求變更的走向。我們都知道大部分人是做不到的，所以大部分人就算精通設計模式也多少會做錯點什么東西。所以這其實不怪設計模式，怪產(chǎn)品狗。
所以說如何避免過度設計，這就要求你深入的理解你的程序所在的領域的知識，了解用戶使用你的軟件是為了解決什么問題，這樣你預測用戶的需求才會比以前更加準確，從而避免了你使用設計模式來封裝一些根本不會發(fā)生的變化，也避免了你忽視了未來會發(fā)生的變化從而發(fā)現(xiàn)你使用的模式根本不能適應需求的新走向。
所以，在你滿足了【知道所有設計模式為什么要被發(fā)明出來】的前提之后，剩下的其實都跟編程沒關系，而跟你的領域知識和領域經(jīng)驗有關系。
架構設計中應該注意的事情
我的觀點是，一切隱藏都是對代碼復雜性的增加，除非它帶來了好處，例如達到了代碼復用，提高了代碼的可維護性等，否則，沒有好處的封裝只會給代碼閱讀理解帶來成本。 ——唐巧
所以，在這份理所當然的SDK的背后，蘊藏著大牛門幾十年的設計智慧。當中應該能夠看到很多門道。這次就UIView和CALayer來分析，就可以得出一些東西。
- 機制與策略分離
- 更多的不可變
- 各司其職
- 漏的更少
機制與策略分離
Unix內(nèi)核設計的一個主要思想是——提供(Mechanism)機制而不是策略(Policy)。編程問題都可以抽離出機制和策略部分。機制一旦實現(xiàn)，就會很少更改，但策略會經(jīng)常得到優(yōu)化。例如原子可以看做是機制，而各種原子的組成就是一種策略。CALayer也可以看做是一種機制，提供圖層繪制，你們可以翻開CALayer的頭文件看看，基本上是沒怎么變過的，而UIView可以看做是策略，變動很多。越是底層，越是機制，越是機制就越是穩(wěn)定。機制與策略分離，可以使得需要修改的代碼更少，特別是底層代碼，這樣可以提高系統(tǒng)的穩(wěn)定性。
更多的不可變
穩(wěn)定給你的是什么感覺？堅固？不可形變？穩(wěn)定其實就是不可變。一個系統(tǒng)不可變的東西越多，越是穩(wěn)定。所以機制恰是滿足這個不可變的因素的。構建一個系統(tǒng)有一個指導思想就是盡量抽取不可變的東西和可變的東西分離。水是成不了萬丈高樓的，堅固的混凝土才可以。更少的修改，意味著更少的bug的幾率。
各司其職
即使能力再大也不能把說有事情都干了，萬一哪一天不行了呢，那就是突然什么都不能干了。所以僅僅是基于分散風險原則也不應該出現(xiàn)全能類。各司其職，相互合作，把可控粒度降到最低，這樣也可以是系統(tǒng)更穩(wěn)定，更易修改。
漏的更少
接口應該面向大眾的，按照八二原則，其實20%的接口就可以滿足80%的需求，剩下的80%應該隱藏在背后。因為漏的少總是安全的，不是嗎。剩下的80%專家接口可以隱藏與深層次。比如UIView遮蔽了大部分的CALayer接口，抽取構造出更易用的frame和動畫實現(xiàn)，這樣上手更容易。
沉默是金，簡潔是靈魂
如果一個人的回答又長又復雜，那搞不好就是因為他自己也不知道答案，或者沒有這個能力辦好這件事。我們應該給出簡短概括的答案。但是世上永遠不會缺八卦新聞。有些事其實并不確切，有人還不厭其煩地傳來傳去，打攪當事人。
