一、多聚合，少繼承.高內聚、低耦合 高內聚、低耦合 內聚：每個模組儘可能獨立完成自己的功能，不依賴於模組外部的程式碼。 耦合：模組與模組之間介面的複雜程度，模組之間聯絡越複雜耦合度越高，牽一髮而動全身。 目的：使得模組的“可重用性”、“移植性”大大增強 通常程式結構中各模組的內聚程度越高，模組間的耦合程度就越低
模組粒度：       『函式』            高內聚：儘可能類的每個成員方法只完成一件事（最大限度的聚合）            低耦合：減少類內部，一個成員方法呼叫另一個成員方法       『類』            高內聚低耦合：減少類內部，對其他類的呼叫       『功能塊』            高內聚低耦合：減少模組之間的互動複雜度（介面數量，引數資料） 個人總結: 1.使用介面來解耦合.耦合針對類，不針對介面? 參考:

http://www.cnblogs.com/edisonfeng/archive/2011/12/22/2298048.html http://www.cnblogs.com/robnetcn/archive/2012/04/15/2449008.html
二、面向物件5個基本原則 1. 單一職責(職責劃分能力) 定義:      應該有且僅有一個原因引起類的變更。個人認為也適應用於一個模組、一個介面、一個方法職責單一,甚至一個服務.     單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則
職責是什麼?     一個類實現的功能或服務
職責劃分(困難點):      我認為職責可以拆分成子職責.根據模型結構劃分職責(也可以直接說功能)
職責擴散:    一個職責變成了多個
優點: 程式碼可讀性較好、複用性比較高等
缺點: 繁瑣(過多的類)、維護困難等
其它:   軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離.判斷是否分離出來的依據為如果你能夠想到多於一個的動機去改變一個類，那麼這個類就具有多一個的職責.
個人理解: 以後臺個人新籤功能為例,主要功能包括新增客戶資訊,新增合同住人資訊,填寫租賃資訊
思考: 突然有一天APP增加了個人新籤功能.
參考:

https://www.douban.com/note/330096938/ http://www.cnblogs.com/dolphin0520/p/3919839.html http://blog.csdn.net/shiyuan17/article/details/9087273 http://www.jdon.com/designpatterns/the-single-responsibility-principle.html http://blog.csdn.net/yuanlong_zheng/article/details/7423000 <<大話設計模式>>
2.  開放封閉原則(抽象能力) 定義: 軟體實體（類、模組、方法等）應該可以擴充套件，但是不可修改。 基本思想: Open(Open for extension): 模組的行為必須是開放的、支援擴充套件的，而不是僵化的。 Closed(Closed for modification): 在對模組的功能進行擴充套件時，不應該影響或大規模地影響已有的程式模組。
優點:可擴充套件，靈活性
缺點:過度抽象,導致本該簡單的設計複雜化.
2.如何遵守開放-封閉原則
實現開放-封閉的核心思想就是對抽象程式設計，而不對具體程式設計，因為抽象相對穩定。讓類依賴於固定的抽象，這樣的修改就是封閉的；而通過面向物件的繼承和對多型機制，可以實現對抽象體的繼承，通過覆寫其方法來改變固有行為，實現新的擴充套件方法，所以對於擴充套件就是開放的。
1）在設計方面充分應用“抽象”和“封裝”的思想。 一方面也就是要在軟體系統中找出各種可能的“可變因素”，並將之封裝起來； 另一方面，一種可變性因素不應當散落在多個不同程式碼模組中，而應當被封裝到一個物件中。
2）在系統功能程式設計實現方面應用面向介面的程式設計。 當需求發生變化時，可以提供該介面新的實現類，以求適應變化。 面向介面程式設計要求功能類實現介面，物件宣告為介面型別。在設計模式中，裝飾模式比較明顯地用到了OCP。
總結 開放封閉原則要求 設計人員能針針對程式中頻發變化的那些部分做出抽象. 在我們最初編寫程式碼的時,假設變化不發生。當變化發生時，我們就建立抽象隔離以後發生的同類變化。 面對需求,對程式的改動是通過新增程式碼進行的，而不是更改現有的程式碼。--此處的需求應該是新需求即新功能.
個人理解:   1). 開放封閉原則是針對模組這種可包含多個功能的實體，進行功能上的擴充套件, 以後臺新籤為列，新籤包括了很多功能，這個功能可以很容易的實現擴充套件，不需要再改變已有類(只是功能實現類不包含呼叫該功能的類--客戶端)的基礎上.   2). 定義中的軟體實體包括了方法，方法能使用該原則?方法應該是最小li度的功能，無法擴充套件只能修改?
例子：
參考: http://www.2cto.com/kf/201609/550408.html http://www.infoq.com/cn/news/2013/05/open-closed-principle-challenged http://blog.csdn.net/ithzhang/article/details/7533627 http://www.cnblogs.com/TerryFeng/archive/2009/11/30/1613648.html http://blog.163.com/lingjingtianbian@126/blog/static/46066361201372334512937/ http://blog.csdn.net/a980150976/article/details/40779497 <<大話設計模式>> http://wenku.baidu.com/link?url=v01qX_AY6fMEzkavjqNq9niNxAEnaWFduNaW06juONk4EZXf9Za1h4sUuQBe3XNkNIl6Qq_meRHwY5ggMBjAFcfuSlXcCqHUq-MWR3PH5iy
3. 里氏替換原則
參考: http://www.studyofnet.com/news/482.html http://wenku.baidu.com/link?url=v01qX_AY6fMEzkavjqNq9niNxAEnaWFduNaW06juONk4EZXf9Za1h4sUuQBe3XNkNIl6Qq_meRHwY5ggMBjAFcfuSlXcCqHUq-MWR3PH5iy
4. 依賴倒置原則
5. 介面分離原則
參考: http://youyu4.iteye.com/blog/2159569 http://blog.csdn.net/zhengzhb/article/details/7296921 http://blog.csdn.net/u010255127/article/details/50955163 http://www.cnblogs.com/shao-shao/articles/3413644.html http://blog.csdn.net/yumuhu/article/details/6240135
3. 待說明     職責和功能的區別.