開放封閉原則就是在開發過程中開發實體（類，模組，函式等）應該可以擴充套件，但是不能修改。是物件導向的核心設計所在。
**要容易維護又不容易出問題，就要多擴充套件，少修改。俗話說磨刀不誤砍柴工，在設計的時候可以先猜測最有可能發生變化的地方（可能頻繁發生變化的地方），然後建立抽象來隔離變化。這需要我們在專案中多思考，多積累經驗。
在oc中可以用來實現開放封閉的有1.繼承，2.category，3.protocol
protocol能提供一套公用的介面，並不提供具體的實現，只負責生命不管誰去實現，如何去實現，這樣任意的類在需要的時候都可以用不同的方式去實現介面中的方法，比如我們最常用的tableview，tableview的各種展現出來的樣子，都是我們通過他的一系列datasource和delegate的具體實現來賦予的，可以說是非常經典的例子。
category是對乙個類的一種補充，擴充套件，就像乙個東西的基本功能完成了，可以用category為這個類新增不同的元件以滿足不同情況的需求，跟protocol的區別是category即提供介面也提供具體的實現。category可以把乙個比較複雜龐大的類分成不同模組，在不同的類中來實現。category有個缺點就是當乙個方法已經在其他的category中定義過，這洋酒無法確定那個定義的方法會被呼叫。如果乙個方法在不同的情況下需要不同的實現，請使用protocol。
繼承，他既可以像protocol一樣只提供純粹的介面，也可以像category一樣提供具體的實現，可以擴充套件例項變數，也可以對已經實現的方法進行改寫，繼承很強大，但是使用繼承進行擴充套件是一種耦合度很高的的行為，對父類是完全的依賴，如果繼承體系太過複雜，很難維護，如果僅僅是對類進行擴充套件，不建議使用繼承。在具體使用時要自己來分析確定，耦合性，依賴性一定要低。繼承使用最多的應該是在介面或者功能上需要復用時，把相似的地方提取到基類裡面，然後各個子類繼承這個基類，實現各自的特殊部分，在寫乙個功能或者介面時思考一下以後是否有可能復用，在應對以後的需求時會讓自己從容很多。category可以被繼承，在某個父類中定義了category，那麼他的所有子類都具有該category
這是第一篇技術部落格，參考了很多大神的內容，但是也加入一些自己的感悟，一字一字打出來也是乙個思考的過程。原來覺得沒有什麼高深的內容寫出來被人看見只會被人笑話，現在覺得不管再淺顯的東西，總結一下寫出來總會有更深的理解。
黎克特制替換原則在現實中的應用
我記得在之前xx大型的網際網路公司，該公司只能算是很偽的網際網路公司，以業務為主，非技術指導的公司，所以裡面的寫業務的人員水平也是參差不齊，在不停地重構，沒過多久又會發現 的維護難度在增加，然後又是重構，出現了惡性迴圈。每次來了新需求，都會頭疼得緊，擔心需求的改變會對上乙個版本有很大的衝擊。今天來介...
設計原則在手機攝影中的運用
為了給在校的最後一年留下紀念，最近我總是拿著手機溜達到校園的角落拍照。手機拍照很容易分享。我漸漸發現，那些最受朋友喜愛的 無意識中符合了某些設計原則。這些原則交錯遊走，不斷遵循和打破，最終定格成下面的一張張 如果說藝術是對生活的提煉，那麼攝影就是對視覺的提煉。所謂的 提煉 就是從日常看到的東西中做減...
盡早崩潰原則在遊戲引擎中的實踐
很多程式設計師喜歡辯解說 盡早崩潰 是最佳實踐 在遇到問題的第一時刻報錯，報得越早越好，畢竟越接近問題發生的第一現場越方便他們除錯。這個說法本身當然是沒問題的 如果你用個預設值糊弄一下，或者是寫某種容錯邏輯來忍耐了破壞假定的行為，那麼錯誤很有可能會蔓延到之後更加遠離出問題的地方才爆發，那時丟失了源頭...