1. 程式人生 > >程式碼設計的一些原則

程式碼設計的一些原則

1,OCP(Open-Close Principle)開閉原則
Software entities should be open for extension,but closed for modification,(在設計一個模組的時候,應當使這個模組可以在不被修改的前提下擴充套件)。
對擴充套件開放open,對修改關閉close。
如何實現?1,抽象化是關鍵,2對可變性的封裝原則(Principle of Encapsulation of Variation EVP)。
用我自己的話來說,在我們設計模組的時候,要將其他“類似”的類,提取出來共同的程式碼,就是所謂的“抽象”。而對於哪些程式碼放在抽象類裡面去,就是存在可變性的地方.對於這點,我還沒有體會到。   
典型容易理解的例子,工廠模式。當需要新增加一個類的時候,直接繼承product介面就可以了。OCP~
 
2,Liskov Subsitution Principle(LSP)里氏代換原則
就是子類可以代替父類出現的任何地方,在抽象的時候,重要的要理解的一個地方兩個類之間是什麼關係,是“has-A”?還是“Is-a”的關係。在 “has-a”的關係中,兩個類存在的是依賴的關係(在類A裡面存在類B的的變數);在“Is-a”的關係中,可以提取這兩個類的“共同程式碼”放在抽象類 C中,然後A,B繼承與C,這也是一種重構。
  
3,Dependency Inversion Principle(DIP)依賴倒轉原則
就是在我們程式設計的時候方法的引數型別,變數,對於其他具體類的依賴,我們儘量的使用抽象類。
就是說盡量依賴於抽象,而不是依賴於實現。
在書中兩種表述:
(1),Abstraction should not depend on details.details should depend on abstraction. (抽象不應當依賴於細節,細節應當依賴於抽象)。Abstraction就像是建築物的基礎,而其實現類就是在基礎上面一層一層的往上面走。你拆掉最上面那層,和拿走最下面的基礎,有什麼不同了,這就是差異了。所以Abstraction是要相當的穩定,是維護的重點。也正是因為穩定,所以我們儘量的依賴於Abstraction,既是穩定系統,也是靈活系統。
(2),Program to an Interface,not an implementation(要針對介面程式設計,不要針對實現程式設計)
應當使用java介面和抽象java類進行變數的型別宣告,引數的型別宣告,方法返回值的型別和資料型別的轉換。
在這裡我就有一個問題了。
List l=new Vector();而不要使用 Vector l=new Vector();我就有疑問 如果我一個類B 繼承於類A,B有一些A不存在的方法,而我的方法中我得使用B,這裡那就菜了。
所以看到這句話了。保證做到這點,一個具體的類應當只實現Java介面,和抽象java類中宣告過的方法,而不應當給出多餘的方法。  
依賴倒裝原則是很難實現的,在這些原則中,因為從上面也可以看到。還是使用了Vector類這個具體的類,還是對具體的類有依賴,所以,對於依賴倒裝的建立new Vector(),有一個專門的模式,工廠模式,不過只是把違反這個原則的地方壓縮到一個類裡面。

4,Interface Segregation Principle(ISP)介面隔離原則
限制一個實體對另一個實體通訊時候的寬度。
就是一個類對另外一個類依賴的時候,應當是建立在最小的介面上面。對於介面隔離原則來說,有兩種介面,一種是真正意義上面的“java 介面”Interface;另外一種是指一個類的方法的集合。對於這來兩種有,兩個介面隔離的原則,對於一個類裡面的方法的集合的介面隔離,我們稱作是 “角色隔離原則”;另外一種叫做“定製服務”。
定製服務,就是一個類,我給你這個客戶端一些方法,我放在一個java介面(Interface)裡面。給另外一個客戶端另外一些方法,放在另外一個介面(Interface).
角色隔離原則,是指客戶端要多個不同的類的方法,我們就搞幾個不同類別的介面(Interface),在書中,這麼比喻的,就相當於電影劇本里面的人物,我們找人來演,這個人就是具體的類。這就叫做角色隔離原則。
 
5,Composition/Aggregation Reuse Principle(CARP)組合/聚合複用原則
就是說要儘量的使用合成和聚合,而不是繼承關係達到複用的目的。
其實這裡最終要的地方就是區分“has-a”和“is-a”的區別。相對於合成和聚合,繼承的缺點在於:父類的方法全部暴露給子類。父類如果發生變化,子類也得發生變化。聚合的複用的時候就對另外的類依賴的比較的少。
 
6,Least Knowledge Principle(LKP)最少知識原則,又稱為“Law of Demeter”迪米特原則。
和ISP介面隔離原則一樣,限制類與類之間的通訊。ISP限制的是寬度,而LoD迪米特原則限制的是通訊的廣度和深度。
LoD在廣度上面,儘量減少遠距離類的關聯,而使用與自己有關的類,並且也與遠距離類有關的類。
可是這種做法有一點麻煩。多個遠距離類產生關聯的時候,不怎麼容易處理,所以增加一個遠距離類的抽象類。所有的遠距離類都是通過抽象類的形式來訪問。
在深度上面,控制權限是最重要的,對於類,一個是default 和public,儘量最小許可權;對於成員,private,default,protected,public。往上面走,許可權越小,依賴的耦合就越小。
有幾種描述:
(a)Only talk to your immediate friends.
(b)Don't talk to strangers.
設計模式“facade”,"調停者模式"。在這裡是IoD的典型表現。

相關推薦

重構-改善既有程式碼設計-重構原則(1)

神馬是重構?從兩方面來說: 一個是名詞:對軟體內部結構的一種調整,目的是在不改變軟體可觀察行為的前提下,提高其可理解性,降低其修改成本。 一個是動詞:使用一系列重構手法,在不改變軟體可觀察行為的前提下,調整其結構。 對重構的擴充套件: 1.重構的目的是使軟體更容易被理解和修改。(

程式碼設計 六大原則

單一職責原則 Single Responsibility Principle 定義:一個類或者一個介面,最好只負責一項職責。 問題由來:類T負責兩個不同的職責P1和P2。由於職責P1需要發生改變而需要修改T類,就有可能導致原來執行正常的職責P2功能發生故障。

程式碼設計一些原則

1,OCP(Open-Close Principle)開閉原則 Software entities should be open for extension,but closed for modification,(在設計一個模組的時候,應當使這個模組可以在不被修改的前提下

重構之重構原則(一)重構改善既有的程式碼設計(重構原則

目錄 兩頂帽子 新增新功能 重構 為何重構 重構的難題 重構與設計 間接層和重構(間接層的價值) @(重構)[原則|操作|問題] 重構:對軟體內部結構的一種調整,目的是再不改變軟體的可觀察行為的前提下,提高其可理解性,降低其修改成本。

漫談開發設計中的一些原則”及“設計哲學”

在開發設計中有一些常用原則或者潛規則,根據筆者的經驗,這裡稍微總結一下最最常用的,以饗讀者。 DRY 這裡的DRY是Do Not Repeat Yourself的縮寫。具體解釋參見 ,嚴謹的定義是 Every piece of knowledge must have a

重構 改善既有程式碼設計——重構原則

1.何謂重構? 答: A.重構(名詞意義):對軟體內部結構的調整,目的是在不改變軟體可觀察行為的前提下,提高其理解性,降低其修改成本; B.重構(動詞意義):使用一系列重構手法,在不改變軟體可觀察行為的前提下,調整其結構; 總結:為了更容易理解和修改軟體,在不改變軟體功能的

測試概念進行程式碼設計時的七條基本原則

當設計大型程式的時候,您必須時刻留心不同設計選項對諸如效能和可擴充套件性這樣的特徵的影響。隨著軟體產品的日漸複雜及其無所不在的部署,軟體的“可測試性”也成了更重要的考慮事項。   徹底測試程式碼的重要性是顯然的。花在編寫測試和測試程式碼上的時間和精力給您帶來的回報是維護成本的

《億級流量網站架構核心技術》讀書筆記 —— 交易型系統設計一些原則

設計一個系統,不僅需要考慮實現業務功能,還要保證系統高併發、高可用、高可靠等,在系統容量規劃(流量、容量)、SLA指定(吞吐量、響應時間、可用性、降級方案等)、壓測方案(線上、線下等)、監控報警(機器負載、響應時間、可用率等)、應急預案(容災、降級、限流、隔離、

程式碼設計的幾個基本原則

1,OCP(Open-Close Principle)開閉原則 Software entities should be open for extension,but closed for modification,(在設計一個模組的時候,應當使這個模組可以在不被修改的前提

基於測試概念進行程式碼設計的七條基本原則

當設計大型程式的時候,您必須時刻留心不同設計選項對諸如效能和可擴充套件性這樣的特徵的影響。隨著軟體產品的日漸複雜及其無所不在的部署,軟體的“可測試性”也成了更重要的考慮事項。 徹底測試程式碼的重要性是顯然的。花在編寫測試和測試程式碼上的時間和精力給您帶來的回報是維護成本的大幅

程式碼設計的六大原則

開了部落格,為了能夠更好的學習,對於自己不瞭解和還沒有掌握的知識加以歸類,鞏固以及加強。現在主要針對的是程式碼設計的原則,在設計程式碼的時候,不能總是想到哪就打到哪,還需要有個大致的流程,否則寫出來的程式碼也是很繁冗,不夠簡潔。對於自己的程式碼程式設計還沒達到一個期望的程度,

程式碼設計的幾個基本原則

1、OCP(Open-Close Principle)開閉原則 Software entities should be open for extension,but closed for modification,(在設計一個模組的時候,應當使這個模組可以在不被修改的前提下擴充套件)。 對擴充套件開放op

一些軟體設計原則

 以前本站向大家介紹過一些軟體開發的原則,比如優質程式碼的十誡和Unix傳奇(下篇)中所以說的UNIX的設計原則。相信大家從中能夠從中學瞭解到一些設計原理方面的知識,正如我在《再談“我是怎麼招聘程式”》中所說的,一個好的程式設計師通常由其操作技能、知識水平,經驗層力和能力

索引設計一些原則

1.分割槽表不要建立全域性索引     分割槽表一般建立本地索引(使用local關鍵字)。刪除分割槽時全域性索引失效。 2.不要建立無用索引     會降低DML語句的效能。 3.不要建立同樣功能的索引     比如:如果已經建立了(colName1,colName2)索引

設計模式學習筆記(二) 設計基本原則之【單一職責原則

code 分享 開發者 實際應用 需要 ret ext file類 tor 單一職責原則(SRP: Single Responsibility Principle) 名詞解釋: 1) 職責:是指類變化的原因。 2) 職責擴散:就是因為某種原因,職責P被分化為粒度更細的職責P

設計模式原則(3)--Dependency Inversion Principle(DIP)--依賴倒轉原則

以及 .get 依賴註入 不能 通過 而是 耦合度 面向實現 看書 1.定義:   高層模塊不應該依賴低層模塊,二者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。   抽象不應該依賴於細節,細節應當依賴於抽象。換言之,要針對接口編程,而不是針對實現編程。 2

php設計六大原則

維護 而不是 data 細節 cto 擴展 框架 基類 完成 1.單一職責 定義:不要存在多於一個導致類變更的原因。通俗的說,即一個類只負責一項職責。 優點: 1)、可以降低類的復雜度,一個類只負責一項職責,邏輯簡單; 2)、提高類的可讀性,提高系統的可維護性; 3)、變更

Restful API 設計參考原則

width 包裝 修改 api開發 司機 word 屬性 add 數據返回 在項目中,需要為後臺服務撰寫API。剛開始接觸的時候,並沒有考慮太多,就想提供URL,服務端通過該URL進行查詢、創建、更新等操作即可。但再對相關規範進行了解後,才發現,API的設計並沒有那麽簡單,

自動化測試用例設計原則

自動化 多少 target 刪除 問題 正是 測試工具 例子 解決方案 自動化測試用例設計的原則 很多公司在實施自動化測試的過程中,往往會把所有的手工測試用例作為自動化測試用例,並且直接進行腳本的開發工作,甚至有些公司不寫自動化測試用例,直接想當然地開發測試腳本,這些都是

西遊記之設計模式原則——單一職責原則

void 可能 equals main person 方法 隱患 客戶端代碼 p s 單一職責原則 ——專心致誌只做一件事 1 package danyizhize; 2 3 class SunWuKong { 4 public void XiangM