1. 程式人生 > >設計模式六大原則的理解(一)

設計模式六大原則的理解(一)

       面向物件三大特徵:“封裝”,“繼承”,“多型”碼農們都能順口唸出,但設計模式的三大原則能準確說出的就不多了。這三大原則是“開放-封閉原則“,”里氏代換原則”和“依賴倒轉的原則”。

     開放---封閉原則:

 軟體實體可以擴充套件,但是不可以修改(當然錯誤是必須修改的,這裡的修改常指需求改變、增加)。即對於開展是開放的,對於修改是封閉的。面對需求,對程式的改動是通過增加程式碼來完成的,而不是改動現有程式碼。

     里氏代換原則

一個軟體實體如果使用的是一個父類的話,那麼一定適用於其子類。而且他察覺不出父類和子類物件的區別。也就是說:在軟體裡面把父類替換為子類,程式的行為沒有變化。

      依賴倒轉原則

      抽象不應該依賴細節,細節應該依賴抽象。即針對介面程式設計,不要實現程式設計。高層模組不能依賴低層模組,兩者都應該依賴抽象。

     依賴倒轉原則是面向物件的標誌,用哪種語言編寫程式不重要,如果編寫時考慮的是如何針對抽象程式設計而不是針對細節程式設計,即程式的所有依賴關係都終止於抽象類或介面。那就是面向物件設計,反之那就是面向過程的設計。

       這三大原則和麵向物件三大特徵的關係? 三大原則的實現就是基於三大特徵而來。

PS:

       C能不能面向物件?

       答案是肯定的,OOP是一種思想,跟語言無關,只是新興程式語言發明時候就考慮了對面向物件的支援,提供了相關關鍵字和語法。作為擁有指標,能寫作業系統核心的語言,面向物件難不倒C。

       Linux把所有的裝置都抽象為檔案,對所有的裝置的操作都可以通過對“檔案描述符”的讀寫來實現,而不需要去了解其實現細節。這就是一種完美的OO設計。

       C可以使用struct來實現封裝,通過函式指標來實現成員函式。只包含函式指標成員的struct,就是一個完美的抽象介面實現。一個struct包含另一個struct這就實現了繼承。當然實際使用上是肯定沒有C#,Java,C++那麼方便的,但C永遠有它們比不過的地方。

相關推薦

設計模式六大原則例子-- 介面隔離原則ISP例子

之前我們對設計模式的六大原則做了簡單歸納,這篇部落格是對介面隔離原則進行的舉例說明。 1介面隔離原則的意義 建立單一介面,不要建立龐大臃腫的介面,儘量細化介面,介面中的方法儘量少。也就是說,我們要為各個類建立專用的介面,而不要試圖去建立一個很龐大的介面供所有依賴它的類去呼叫。 在程式設計中,依賴幾個

設計模式六大原則例子-- 單一職責原則SRP例子

之前我們對設計模式的六大原則做了簡單歸納,這篇部落格是對單一職責原則進行的舉例說明。 單一職責原則的意義 物件不應該承擔太多職責,正如人不應該一心分為二用。唯有專注,才能保證物件的高內聚;唯有單一,才能保證物件的細粒度。物件的高內聚與細粒度有利於物件的

基本設計模式學習筆記:常見的七種面向物件設計原則

0.概述      面向物件設計原則為支援可維護性複用而誕生,這些原則蘊含在很多設計模式中,他們是從許多設計方案中總結出來的指導性原則1.單一原則     一個類只負責一個功能領域中的相應職責,或者說:就一個類而言,應該只有一個引起它變化的原因。個人總結:將不同職責的方法放在

設計模式之問題集錦

是把 後繼 ogr data- 跟著 沒有 解釋器 space 基本實現 設計模式的主要資料是《大話設計模式》。第一階段先看看各種模式的基本概念。實現每一個模式下的樣例。然後在進行理解性的學習和掌握,靈活掌握各種模式的長處,知道某種模式適合那種狀態。如今,樣

Java設計模式之總體簡介——簡單易懂

設計模式(Design pattern)是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問,設計模式於己於他人於系統都是多贏的,設計模式使程式碼編制真正工程化,設計模式是

設計模式——java版》

        一、設計模式簡介         1. 設計模式是一套被反覆使用、多數人知曉、經過分類編目的優秀程式碼設計經驗的總結。使用設計模式是為了重用程式碼,使程式碼更容易理解並保證程式碼的可靠性。 &

Koffee設計模式學習之路 —— 模式學習總結思路

    這篇部落格沒有相關技術細節,僅作為自己對設計模式這個東西的一點感悟和以後設計模式系列部落格的一個寫作思路。     作為非科班出身,誤打誤撞進入程式設計的人,在上研究生期間對於程式的唯一要求就是:能用。彼時,不知道有面向物件,記憶體管理,多執行緒,

Javascript設計模式之簡單工廠

建立型設計模式-簡單工廠模式 簡單工廠模式(Simple Factory):又稱之為靜態工廠模式,由一個工廠物件建立某一種產品物件類的例項。主要用來建立同一類物件。 多類單例項法 為了加深我們的理解,設定以下需求。假設一個大型超市賣各種東西,

代理模式的自我理解

delegate的函式往往要通過某些事件的觸發,才會自動呼叫的;比如uitableview的didselectrow函式,由於tableview.delegate=self等於自身,所以當觸發這個事件的時候,就會呼叫協議中的一個方法,而這個方法的實現就由self來實現,還有

設計模式六大原則理解

       面向物件三大特徵:“封裝”,“繼承”,“多型”碼農們都能順口唸出,但設計模式的三大原則能準確說出的就不多了。這三大原則是“開放-封閉原則“,”里氏代換原則”和“依賴倒轉的原則”。      開放---封閉原則:  軟體實體可以擴充套件,但是不可以修改(當然錯誤

python 設計模式 --- 六大原則

單一職責原則(SRP:Single responsibility principle),一個類或者模組應該有且只有一個改變的原因,例如,搓衣板,既可以用來跪,也可以用來洗衣服。而在單一職責原理下,搓衣板的兩個功能就是引起這個類變化的兩個原因,就應該寫成兩個類 # -*-

設計模式六大原則-- 介面隔離原則ISP

  設計圖和原始碼請訪問作者的github:https://github.com/yangsheng20080808/DesignModel From Now On,Let us begin Design Patterns。 介面隔離原則 Interface Segregati

設計模式六大原則6:開閉原則

思考 外部 編程人員 恰恰 單一職責 何事 適應 擴展 分享 開閉原則 定義:一個軟件實體如類、模塊和函數應該對擴展開放,對修改關閉。 問題由來:在軟件的生命周期內,因為變化、升級和維護等原因需要對軟件原有代碼進行修改時,可能會給舊代碼中引入錯誤,也可能會使我們不得不對

設計模式六大原則2:裏氏替換原則

tr1 裏氏替換原則 style tar 裏氏替換 href target 替換 設計模式 XN潮寺贛3PF鋁73瓷Hhttp://weibo.com/p/1005056364252732 壇2偈6v實8uka誆敲wmhttp://weibo.com/p/10050563

設計模式六大原則

method 過多 這樣的 不同 提高 依賴倒置 同心圓 23種設計模式 變化 設計模式六大原則(1):單一職責原則 定義:不要存在多於一個導致類變更的原因。通俗的說,即一個類只負責一項職責。 問題由來:類T負責兩個不同的職責:職責P1,職責P2。當由於職責P1需求發

設計模式六大原則4:接口隔離原則

說明 兩個 復雜 試圖 所有 類圖 系統 客戶端 face 定義:客戶端不應該依賴它不需要的接口;一個類對另一個類的依賴應該建立在最小的接口上。 問題由來:類A通過接口I依賴類B,類C通過接口I依賴類D,如果接口I對於類A和類B來說不是最小接口,則類B和類D必須去實現他

設計模式設計原則簡介

  什麼是設計模式? 我們知道對於很多數學問題,經常會有多種不同的解法 而且這其中可能會有一種比較通用簡便高效的方法 我們在遇到類似的問題或者同一性質的問題時,也往往採用這一種通用的解法 將話題轉移到程式設計中來 對於軟體開發人員, 在軟體開發過程中,

設計模式六大原則詳細 設計模式六大原則

設計模式六大原則 轉自https://www.cnblogs.com/shijingjing07/p/6227728.html 1.設計模式的目的設計模式是為了更好的程式碼重用性,可讀性,可靠性,可維護性。 2.常用的六大設計模式1)單一職責原則2)里氏替換原則3)依賴倒轉原則4)介面

設計模式六大原則3:依賴倒置原則

定義:高層模組不應該依賴低層模組,二者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。 問題由來:類A直接依賴類B,假如要將類A改為依賴類C,則必須通過修改類A的程式碼來達成。這種場景下,類A一般是高層模組,負責複雜的業務邏輯;類B和類C是低層模組,負責基本的原子操作

設計模式六大原則4:介面隔離原則

定義:客戶端不應該依賴它不需要的介面;一個類對另一個類的依賴應該建立在最小的介面上。 問題由來:類A通過介面I依賴類B,類C通過介面I依賴類D,如果介面I對於類A和類B來說不是最小介面,則類B和類D必須去實現他們不需要的方法。 解決方案:將臃腫的介面I拆分為獨立的幾個介面,