重新認識面向對象：
>了解隔離變化
·從宏觀層面來看,面向對象的建構方式更能适應軟體的變化,能将變化所帶來的影響減為最小
>各司其職
從微觀層面來看,面向對象的方式更強調各個類的“責任”
由于需求變化導緻的新增類型不應該影響原來類型的實作--是所謂各負其責
>對象是什麼?
從語言實作層面來看,對象封裝了代碼和資料。
從規格層面講,對象是一系列可被使用的公共接口。
從概念層面講，對象是某種擁有責任的抽象。
面向對象設計原則(1)
>依賴倒置原則(DIP)
高層子產品(穩定)不應該依賴于低層子產品(變化) ,二者都應該依賴于抽象(穩定)。
抽象(穩定)不應該依賴于實作細節(變化) ,實作細節應該依賴于抽象(穩定)。
面向對象設計原則(2)
>開放封閉原則(OCP)
對擴充開放,對更改封閉。
類子產品應該是可擴充的,但是不可修改。
面向對象設計原則(3)
>單一職責原則(SRP)
一個類應該僅有一個引起它變化的原因因。
變化的方向隐含着類的責任。
面向對象設計原則(4)
Liskov替換原則(LSP)
子類必須能夠替換它們的基類(IS-A).
繼承表達類型抽象。
面向對象設計原則(5)
接口隔離原則(ISP )
不應該強迫客戶程式依賴它們不用的方法。
接口應該小而完備。
面向對象設計原則(6)
優先使用對象組合,而不是類繼承
類繼承通常為“白箱複用”，對象組合通常為“黑箱服用”
繼承在某種程度上破壞了封裝性,子類父類耦合度高
而對象組合則隻要求被組合的對象具有良好定義的接口，要求難度
面向對象設計原則(7)
>封裝變化點
使用封裝來建立對象之間的分界層,讓設計者可以在分界層一側進行修改,而不會對另一側産生不良的影響,進而實作層次間的松耦合。
面向對象設計原則(8)
>針對接口程式設計,而不是針對實作程式設計
不将變量類型聲明為某個特定的具體類,而是聲明為某個接口。
客戶程式無需獲知對象的具體類型,隻需要知道對象所具有的接口。
減少系統中各部分的依賴關系,進而實作“高内聚、松耦合”的類型設計方案。