首頁  >  文章  >  管理資訊系統代碼設計中編碼的目的是什麼?

管理資訊系統代碼設計中編碼的目的是什麼?

青灯夜游
青灯夜游原創
2020-08-28 14:16:567977瀏覽

編碼的目的在於:惟一化、規範化、系統化。代碼就是以數字或字元代表各種客觀實體,在系統開過程中設計代碼目的是:惟一化、規範化、系統化。

管理資訊系統代碼設計中編碼的目的是什麼?

程式碼就是以數字或字元代表各種客觀實體,在系統開啟過程中設計程式碼目的為:

1、惟一化;

2、規範化;

3、系統化。

程式設計六大原則

#單一職責原則Single Responsibility Principle

定義:一個類或者一個接口,最好只負責一項職責。

問題由來:類別T負責兩個不同的職責P1和P2。由於職責P1需要改變而需要修改T類,就有可能導致原先運作正常的職責P2功能發生故障。

解決方法:遵循單一職責原則。分別建立新的類別來對應對應的職責;這樣就能避免修改類別時影響到其他的職責;

當遇到職責擴散的時候,在邏輯夠簡單的時候,才可以在程式碼層級上面違反單一職責原則,只有類別中方法數量夠少,才可以在方法層級上違反單一職責原則;

優點:類別的複雜性將會降低,可讀性將會大大提高,維護性也會提高。

里氏替換原則Liskov Substitution Principle

在使用基底類別的地方可以任意使用其子類,能保證子類別完美地替換基底類別;這一種精神其實是繼承機制約束規範的體現。在父類別和子類別的具體實作中,嚴格控制繼承層次中的關係特徵,以確保用子類別取代基底類別時,程式行為不會發生問題,且能正常進行下去。

對於繼承來說,父類別定義了一系列的規範和契約,雖然不強制所有的子類別必須遵從,但是如果子類別對這些非抽象方法任意修改,就會對整個繼承體系造成破環。

如果非要重寫父類別的方法,比較通用的方法是:原來的父類別和子類別都繼承一個更通俗的基類,原有的繼承關係去掉,採用依賴、聚合、組合等關係代替;

原則包含了一下四層意義:

* 子類別可以實作父類別的抽象方法,但不能覆寫父類別的非抽象方法;

* 子類別可以增加自己特有的方法;

* 當子類別的方法重載父類別的方法時,方法的形參要比父類別方法的輸入參數更佳寬鬆;

* 當子類別的方法實作父類別的抽象方法時,方法的回傳值比父類別更嚴格;

依賴倒置原則Dependence Inversion Principle

定義:高層模組不應該依賴低層模組,二者都應該依賴其抽象;抽像不應該依賴細節;細節應該依賴抽象,其核心思想是依賴抽象;

問題由來:類別A直接依賴類別B,假如要將類別A改為依賴類別C,則必須透過修改類別A的程式碼來完成;這種場景下,類別A一般是高層模組,負責複雜的業務邏輯;類B和類C是低層模組,負責基本的原則操作;假如修改類A,會為程式帶來不必要的風險。

解決方案:將類別A修改為依賴介面I,類別B和類別C各自實作介面I,類別A透過介面I來間接與類別B和類別C發生聯繫,則會降低修改類別A的幾率;

在實際中,我們一般需要做到以下三點:

* 低層模組盡量都要有抽象類別或接口,或者兩者都有;

* 變數的宣告類型盡量是抽象類別或介面;

* 使用繼承時遵循里氏替換原則;

##介面隔離原則Interface Segregation Principle

############### ####定義:客戶端不應該依賴它不需要的介面;一個類別對另一個類別的依賴應該建立在最小的介面上,否則將會造成介面污染;類別A透過介面I依賴類別B,類別C透過接口I依賴類別D,如果接口I對於類別A和類別B來說不是最小接口,則類別B和類別D必須去實作它們不需要的方法;######原則的意思是:建立單一接口,不要建立龐大臃腫的接口,盡量細化接口,接口中的方法盡量少;就是說,我們要為每個類建立專用的接口,而不要試圖去建立一個龐大的接口供所有依賴它的類別去呼叫;#########注意,介面盡量小,但是要有限度,對介面進行細化可以提高程式設計彈性,但是如果過小,則會導致介面數量盡量小,使設計複雜化。所以一定要適度,為依賴介面的類別自訂服務,只暴露給呼叫的類別它需要的方法,它不需要的方法則隱藏起來;#########規則:############################################# * 一個介面只服務一個子模組或業務邏輯,服務​​客製化;######* 透過業務邏輯壓縮介面中的public方法,讓介面看起來更精悍;###

* 已經被污染了的接口,盡量修改,如果變更風險太大,則用適配器模式進行轉換;

* 根據具體的業務,深入了解邏輯,用心感知去控制設計思路;

如何實作介面隔離,主要有兩種方法:

1. 委託分離,透過增加一個新的介面類型來委託客戶的請求,隔離客戶和介面的直接依賴,注意這同時也會增加系統的開銷;

2. 多重繼承分離,透過介面的多重繼承來實現客戶的需求;

迪米特法則

定義:一個物件應該對其他物件保持最少的了解,其核心精神是:不和陌生人說話,通俗之意就是一個物件對自己需要耦合關聯調用的類別應該知道的少;這會導致類別之間的耦合度降低,每個類別都盡量減少對其他類別的依賴。

合成復用原則

##原則是盡量使用合成/聚合的方式,而不是使用繼承;

##開閉原則

定義:一個軟體實體如類別、模版和函數應該對擴展,對修改關閉;

解決方案:當軟體需要變化時,盡量透過擴展軟體實體的行為來實作變化,而不是修改現有的程式碼來實現變化;

    單一職責原則:實作類別要職責單一;
  • 芮氏替換原則:不要破壞繼承系統;
  • 依賴倒置原則:面向介面程式設計;
  • 介面隔離原則:設計介面的時候要精簡單一;
  • 迪米特法則:降低耦合;
  • #開閉原則:總綱,對擴展開放,對修改關閉;

更多相關知識,請造訪:

PHP中文網

以上是管理資訊系統代碼設計中編碼的目的是什麼?的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn