OOP程式設計原則與設計模式（1）

                                                                                                            JOHNNY.DENG

PBP/OBP/OOP的特征

PBP(基于過程)：函數、域與生命周期的概念、函數重載、函數模闆、異常處理、範型算法。

OBP（基于對象）：類（接口）、類的生命周期、類模闆。

OOP（面向對象）：繼承、多态。

三個概念步步深入，後者包括前者。其目的是實作軟體開發的可重用性，解決軟體危機（軟體工程思想未引入之前）。

OOP不可避免設計原則的發展與設計模式的産生，這是OOP獨具的特征決定的（正如前面所說，特征的産生是由其産生目的決定的）。

OOP的方法論（高内聚、低耦合、易複用）

OOP的方法論－－如何實作基于OOP特征的抽象?

OCP（Open-Closed Principle）:軟體實體應該擴充開放、修改封閉。

實作：合理劃分構件，一種可變性不應當散落在代碼的很多角落裡，而應當被封裝到一個對象裡；一種可變性不應當與另一個可變性混合在一

起。

DIP(Dependency Inversion Principle):依賴的倒置，擺脫面向過程程式設計思想中高層子產品依賴于低層實作，抽象依賴于具體細節。OOP中要做到

的是，高層子產品不依賴于低層子產品實作，二者都依賴于抽象；抽象不依賴于具體實作細節，細節依賴于抽象。

實作：應該通過抽象耦合的方式，使具體類最大可能的僅與其抽象類（接口）發生耦合；程式在需要引用一個對象時,應當盡可能的使用抽象類

型作為變量的靜态類型,這就是針對接口程式設計的含義。

LSP(Liskov Substitution Principle):繼承思想的基礎。“隻有當衍生類可以替換掉基類，軟體機關的功能不會受到影響時，基類才真正被複

用，而衍生類也才能夠在基類的基礎上增加新的行為。”

ISP（Interface Insolation Principle）:接口功能單一，避免接口污染。

實作：一個類對另外一個類的依賴性應當是建立在最小的接口上的。使用多個專門的接口比使用單一的總接口要好。

SRP(Single Resposibility Principle):就一個類而言，應該僅有一個引起它變化的原因。 如果一個類的職責過多，就等于把這些職責耦合在一起，一個職責的變化可能會抑止這個類完成其他職責的能力。

CARP（Composite/Aggregate Reuse Principle）：設計模式告訴我們對象委托優于類繼承，從UML的角度講，就是關聯關系由于繼承關系。盡量使用合成/聚合、盡量不使用繼承。

實作：在一個新的對象裡面使用一些已有的對象，使之成為新對象的一部分，以整合其功能。

LoD(Law Of Demeter):就是說一個對象應當對其他對象盡可能少的了解。即隻直接與朋友通信，或者通過朋友與陌生人通信。

朋友的定義（或關系）：

（1）目前對象本身。（2）以參量的形式傳入到目前對象方法中的對象。（3）目前對象的執行個體變量直接引用的對象。（4）目前對象的執行個體變

量如果是一個聚集，那麼聚集中的元素也都是朋友。（5）目前對象所建立的對象。

實作：（1）在類的劃分上，應當建立有弱耦合的類。類之間的耦合越弱，就越有利于複用。（2）在類的結構設計上，每一個類都應當盡量降

低成員的通路權限。一個類不應當public自己的屬性，而應當提供取值和指派的方法讓外界間接通路自己的屬性。（3）在類的設計上，隻要有

可能，一個類應當設計成不變類。（4）在對其它對象的引用上，一個類對其它對象的引用應該降到最低。（5）盡量限制局部變量的有效範圍.

設計模式

設計模式是OOP設計原則的細化，粒度有粗有細，應用可大可小。

（待續）