設計模式在我們的開發中是不可或缺的一部分，很多人會說，我沒用那些設計模式啊，我也開發的挺好的，其實不然，我們在開發中都用到了這些設計模式，只不過我們並沒有在意這些，今天我就用開車的方法來解釋一下我們的7個設計原則。

簡述

　　面向物件的設計原則有七個，包括：開閉原則、單一職責原則、里氏替換原則、迪米特原則（最少知道原則）、介面分離原則、依賴倒置原則、組合/聚合複用原則。

1>開閉原則：

　　在面向物件程式設計領域中，開閉原則規定“軟體中的物件（類，模組，函式等等）應該對於擴充套件是開放的，但是對於修改是封閉的”，這意味著一個實體是允許在不改變它的原始碼的前提下變更它的行為。該特性在產品化的環境中是特別有價值的，在這種環境中，改變原始碼需要程式碼審查，單元測試以及諸如此類的用以確保產品使用質量的過程。遵循這種原則的程式碼在擴充套件時並不發生改變，因此無需上述的過程。摘自某度百科。

　　上述那段話我是沒看懂什麼意思（我也沒仔細的去看），開閉原則一句話來解釋就是對擴充套件開放，對修改關閉。

　　我們來舉幾個生活的栗子，小張開了一個飯店，湘菜做的很棒，顧客也越來越多了，也出現了在吃飯時間排隊等候的現象，小張這時意識到我們應該擴張一下我們的飯店的規模了，於是把相鄰的門店也一併租了下來，有人建議小張，你既然擴張了飯店的規模建議你去做一些別的事（嚴重不符合開閉原則），但是小張堅持還是做湘菜（符合開閉原則），也就是說小張你是在於原有的基礎之上做了規模的擴張，而沒有改變飯店原有特色菜的本質，這就是一個開閉原則的栗子。

　　再比如，小張去洗浴中心or足療保健or洗頭房，我們可以點一些***的服務，我們也可以提出一些別的要求，比如花式開心，不管你提什麼要求，也離不開，你想做的那些事的本質，不可能有人要求洗頭小妹給你修腳吧。。。這裡就是我們的可以提出對於***服務的擴充套件花樣，但是不會修改原有***服務的本質。這也就是我們的開閉原則。

　　從程式碼角度來說，就是無論我們如何去擴充套件類的方法和屬性，也不要修改類本質的方法和屬性，只擴充套件不修改現有，也禁止修改原有的屬性。開閉原則是下面那些原則的總綱，切記很重要。

 2>單一職責原則：

　　單一職責原則（SRP：Single responsibility principle）又稱單一功能原則，面向物件五個基本原則（SOLID）之一。它規定一個類應該只有一個發生變化的原因。該原則由羅伯特·C·馬丁（Robert C. Martin）於《敏捷軟體開發：原則、模式和實踐》一書中給出的。馬丁表示此原則是基於湯姆·狄馬克(Tom DeMarco)和Meilir Page-Jones的著作中的內聚性原則發展出的。摘自某度百科。

　　單一職責，這個應該很好理解的，只做一件事，做好一件事就夠了，生活中我們也常常會說，做好一件事不難，難的是一輩子只做這一件事。職責原則一句話來解釋就是請做好自己的事。

　　在生活中栗子有很多的，還是我們的小張開飯店的栗子，上面說了小張的飯店開的很紅火，生意很好，之所以生意會好，是他一直堅持做他的特色菜，很多年了味道一直沒有變過，還是那種熟悉的家鄉味，有人建議他把特色菜的技術融入到燒烤，烤肉上去，小張搖搖頭說，我們這是湘菜館，不是烤肉店，我能一直做好我現在的特色菜就夠了。這就是我們職責單一原則，兩耳不聞別的事，單一隻做一件事。

　　再比如，小張又來足療保健了，不耽誤時間了，直接上樓吧，“來啊，服務員，來盤魚香肉絲”。