程式設計原則(整理)
迪米特法則
迪米特法則(Law of Demeter 或 LoD)又叫做最少知識原則(Least Knowledge Principle或簡寫為LKP),就是說,一個物件應當對其他物件有儘可能少的瞭解。
在軟體系統中,一個模組設計的好不好的最主要、最重要的標誌,就是該模組在多大的程度上將自己的內部資料和其他與實現有關的細節隱藏起來。一個設計好的模組可以將它所有的實現細節隱藏起來,徹底地將提供給外界的API和自己的實現分割開來。這樣一來,模組與模組之間就可以僅僅通過彼此的API相互通訊,而不理會模組內部的工作細節。這一概念就是“資訊的隱藏”,或者叫做“封裝”,也就是大家熟悉的軟體設計的基本教義之一。
資訊的隱藏非常重要的原因在於,它可以使各個子系統之間脫藕,從而允許它們獨立地被開發、優化、使用、閱讀以及修改。
廣義迪米特法則在類的設計上的體現:
1. 優先考慮將一個類設定成不變類
2. 儘量降低一個類的訪問許可權
對於頂級(top-level)的類來說,只有兩個可能的訪問性等級。Package-private和public . 一個類可以設定成為package-private的,就不應該把它設定成為public的。
3. 謹慎使用Serializable
如果一個類實現了Serializable介面的話,客戶端就可以將這個類序列後再並行化。假如以後這個類一旦修改,客戶端勢必也將改動。所以能不用就不用。
4. 儘量降低成員的訪問許可權
開閉原則:
開閉原則講的是:一個軟體實體應當對擴充套件開放,對修改關閉。
抽象化是關鍵
在java語言裡,可以給出一個或多個抽象java類或java介面,規定出所有的具體類必須提供的方法的特徵作為系統設計的抽象層。這個抽象層預見了所有的可能擴充套件。這就使得系統的抽象層不需修改,從而滿足了“開-閉”原則的第二條:對修改關閉。
“開-閉”原則如果從另外一個角度講述,就是所謂的“對可變性的封裝原則”,講的是找到一個系統的可變因素,將之封裝起來。
從“開—閉”原則中可以看出物件導向設計的重要原則是建立抽象化,並且從抽象化匯出具體化。
Java語言中的介面
介面是對可插入性的保證。
介面常見的用法:
1. 單方法介面
顧名思義,一個單方法介面只含有一個方法。Java中Runnable介面要求實現一個run方法。
2. 標示介面
標示介面是沒有任何方法和屬性的介面。標示介面不對實現它的類有任何語義上的要求,它僅僅表明實現它的類屬於一個特定的型別。比如java中的Serializable介面。標示介面通常使用在工具類中,但一般不推薦使用。
3. 常量介面
即用java介面來宣告一些常量。不過不推薦使用這種做法。
抽象類
抽象類應當擁有儘可能少的資料
基於抽象類的模式和原則
1.針對抽象程式設計
應當針對抽象類程式設計,而不是針對具體子類程式設計。
2.正確使用繼承
在java中,繼承關係可以分兩種:一種是對介面的實現,稱作介面繼承;另一種是類對類的繼承,稱作實現繼承。第二種繼承關係是很容易被濫用的一種複用工具。
只要有可能,儘量使用合成(Composition),而不要使用繼承來達到目的。
3.模板方法模式
模板方法模式不僅僅使用抽象類和繼承關係作為對模式所涉及的角色的抽象化,模板方法模式根本就是關於繼承的模式。
4.什麼時候才應當使用繼承複用
繼承代表“一般化/特殊化”關係。
5 .使用繼承關係的條件:
(1.) 子類是超類的一個特殊種類,而不是超類的一個角色。也就是要區分“Has-A”與“Is-A”兩種關係的不同。Has-A關係應當使用聚合關係描述,而只有Is-A關係才符合繼承關係。
(2.) 永遠不會出現需要將子類換成另一個類的子類的情況。
(3.) 子類具有擴充套件超類的責任,而不是具有置換掉(Override)或登出掉(Nullify)超類的責任。
(4.) 只有在分類學角度上有意義時,才可以使用繼承,不要從工具類繼承。
里氏代換原則(【LiskovSubstitution Principle】LSP):
里氏代換原則是繼承複用的基石。只有當衍生類可以替換掉基類,軟體單位的功能不會受到影響時,基類才能被真正被複用,而衍生類也才能夠在基類的基礎上增加新的行為。
里氏代換原則要求凡是基型別使用的地方,子型別一定適用,因此子類必須具備基型別的全部介面。
依賴倒轉原則(【Dependence Inversion】DIP)
實現“開—閉”原則關鍵是抽象化,並且從抽象化匯出具體化的實現。如果說“開—閉”原則是物件導向設計的目標,依賴倒轉原則就是物件導向設計的主要機制。
依賴倒轉原則講的是:要依賴於抽象,不要依賴於具體。
三種耦合關係
1. 零耦合關係:如果兩個類沒有耦合關係,就稱之為零耦合。
2. 具體耦合關係:具體性耦合發生在兩個具體的(可例項化的)類之間,經由一個類對另一個具體類的直接引用造成。
3. 抽象耦合關係:抽象耦合關係發生在一個具體類和一個抽象類(或者java介面)之間,使兩個必須發生關係的類之間存有最大的靈活性。
依賴倒轉原則要求客戶端依賴於抽象耦合。
依賴倒轉原則的表述是:
抽象不應當依賴於細節;細節應當依賴於抽象。
還有一種表述就是:
要針對介面程式設計,不要針對實現程式設計。
針對介面程式設計的意思就是說,應當使用java介面和抽象java類進行變數的型別宣告、參量的型別宣告、方法的返還型別宣告,以及資料型別的轉換等。
聯合使用java介面和java抽象類 Abstract + 介面
介面隔離原則(【Interface Segregation Principle】 ISP)
講的是:使用多個專門的介面比使用單一的介面要好。換言之,從一個客戶類的角度來講:一個類對另外一個類的依賴性應當是建立在最小的介面上的。
角色的合理劃分:
一個介面相當於劇本中的一種角色,而此角色在一個舞臺上由哪一個演員來演則相當於介面的實現。因此,一個介面應當簡單地代表一個角色,而不是多個角色。如果系統涉及到多個角色的話,那麼每一個角色都應當由一個特定的介面代表。
準確而恰當地劃分角色以及角色所對應的介面,是物件導向的設計的一個重要的組成部分。
合成/聚合複用原則(【Composite/Aggregate Reuse Principle】 或CARP)
合成/聚合複用原則就是在一個新的物件裡面使用一些已有的物件,使之成為新物件的一部分;新的物件通過向這些物件的委派達到複用已有功能的目的。
該設計原則有另一個更簡短的表述:要儘量使用合成/聚合,儘量不要使用繼承。
區分“Has-A”與“Is-A”
“Is-A”意思是一個類是另一個類的“一種”。而“Has-A”表示一個類代表另一個類的角色。
轉自:http://blog.csdn.net/xyylchq/article/details/6291925
相關文章
- 設計模式整理--面相對像設計原則設計模式
- 程式設計原則程式設計
- 開閉原則——物件導向程式設計原則物件程式設計
- 【設計原則】物件導向程式設計的六大原則物件程式設計
- 設計原則
- 程式設計師應該遵守的程式設計原則程式設計師
- 設計原則:開閉原則(OCP)
- 設計原則 設計模式設計模式
- 設計模式 - 設計原則設計模式
- 【設計模式】設計原則設計模式
- 物件導向設計原則,以及包的設計原則物件
- 設計原則:介面隔離原則(ISP)
- 設計原則之【介面隔離原則】
- 設計原則-依賴反轉原則
- URI設計原則
- Hbase 設計原則
- XP設計原則
- 安全設計原則
- 極限程式設計中的簡單設計原則程式設計
- 設計模式的設計原則設計模式
- 程式設計師測試原則 - Kent Beck程式設計師
- 優秀程式設計的18個原則程式設計
- 程式設計的首要原則是什麼?程式設計
- 設計原則之【依賴反轉原則】
- 設計原則之【單一職責原則】
- 設計原則之【開放封閉原則】
- 設計原則之【裡式替換原則】
- 軟體設計原則—介面隔離原則
- 軟體設計原則—合成複用原則
- 每個程式設計師都必須遵守的程式設計原則程式設計師
- XML 程式設計思想: Harold 的高效 XML 設計原則(轉)XML程式設計
- SOLID 設計原則Solid
- 系統設計原則
- 設計原則總結
- loc框架設計原則框架
- DDD聚合設計原則
- 微服務設計原則微服務
- Google的設計原則Go