設計模式之六大原則(轉載)

設計模式之六大原則(轉載)數據庫

  關於設計模式的六大設計原則的資料網上不少,可是不少地方解釋地都太過於籠統化,我也找了不少資料來看,發現CSDN上有幾篇關於設計模式的六大原則講述的比較通俗易懂,所以轉載過來。編程

  原做者博客連接:http://blog.csdn.net/LoveLion/article/category/738450/7設計模式

一.單一職責原則

  單一職責原則是最簡單的面向對象設計原則,它用於控制類的粒度大小。單一職責原則定義以下:編程語言

單一職責原則(Single Responsibility Principle, SRP):一個類只負責一個功能領域中的相應職責,或者能夠定義爲:就一個類而言,應該只有一個引發它變化的緣由。編輯器

      單一職責原則告訴咱們:一個類不能太「累」!在軟件系統中,一個類(大到模塊,小到方法)承擔的職責越多,它被複用的可能性就越小,並且一個類承擔的職責過多,就至關於將這些職責耦合在一塊兒,當其中一個職責變化時,可能會影響其餘職責的運做,所以要將這些職責進行分離,將不一樣的職責封裝在不一樣的類中,即將不一樣的變化緣由封裝在不一樣的類中,若是多個職責老是同時發生改變則可將它們封裝在同一類中。函數

單一職責原則是實現高內聚、低耦合的指導方針,它是最簡單但又最難運用的原則,須要設計人員發現類的不一樣職責並將其分離,而發現類的多重職責須要設計人員具備較強的分析設計能力和相關實踐經驗。flex

      下面經過一個簡單實例來進一步分析單一職責原則:this

Sunny軟件公司開發人員針對某CRM(Customer Relationship  Management,客戶關係管理)系統中客戶信息圖形統計模塊提出瞭如圖1所示初始設計方案:flexbox

圖1  初始設計方案結構圖

在圖1中,CustomerDataChart類中的方法說明以下:getConnection()方法用於鏈接數據庫,findCustomers()用於查詢全部的客戶信息,createChart()用於建立圖表,displayChart()用於顯示圖表。

現使用單一職責原則對其進行重構。

      在圖1中,CustomerDataChart類承擔了太多的職責,既包含與數據庫相關的方法,又包含與圖表生成和顯示相關的方法。若是在其餘類中也須要鏈接數據庫或者使用findCustomers()方法查詢客戶信息,則難以實現代碼的重用。不管是修改數據庫鏈接方式仍是修改圖表顯示方式都須要修改該類,它不止一個引發它變化的緣由,違背了單一職責原則。所以須要對該類進行拆分,使其知足單一職責原則,類CustomerDataChart可拆分爲以下三個類:

      (1) DBUtil:負責鏈接數據庫,包含數據庫鏈接方法getConnection();

      (2) CustomerDAO:負責操做數據庫中的Customer表,包含對Customer表的增刪改查等方法,如findCustomers();

      (3) CustomerDataChart:負責圖表的生成和顯示,包含方法createChart()和displayChart()。

      使用單一職責原則重構後的結構如圖2所示:

圖2  重構後的結構圖

二.開閉原則

  開閉原則是面向對象的可複用設計的第一塊基石,它是最重要的面向對象設計原則。開閉原則由Bertrand  Meyer於1988年提出,其定義以下:

開閉原則(Open-Closed Principle, OCP):一個軟件實體應當對擴展開放,對修改關閉。即軟件實體應儘可能在不修改原有代碼的狀況下進行擴展。

      在開閉原則的定義中,軟件實體能夠指一個軟件模塊、一個由多個類組成的局部結構或一個獨立的類

      任何軟件都須要面臨一個很重要的問題,即它們的需求會隨時間的推移而發生變化。當軟件系統須要面對新的需求時,咱們應該儘可能保證系統的設計框架是穩定的。若是一個軟件設計符合開閉原則,那麼能夠很是方便地對系統進行擴展,並且在擴展時無須修改現有代碼,使得軟件系統在擁有適應性和靈活性的同時具有較好的穩定性和延續性。隨着軟件規模愈來愈大,軟件壽命愈來愈長,軟件維護成本愈來愈高,設計知足開閉原則的軟件系統也變得愈來愈重要。

      爲了知足開閉原則,須要對系統進行抽象化設計,抽象化是開閉原則的關鍵。在Java、C#等編程語言中,能夠爲系統定義一個相對穩定的抽象層,而將不一樣的實現行爲移至具體的實現層中完成。在不少面向對象編程語言中都提供了接口、抽象類等機制,能夠經過它們定義系統的抽象層,再經過具體類來進行擴展。若是須要修改系統的行爲,無須對抽象層進行任何改動,只須要增長新的具體類來實現新的業務功能便可,實如今不修改已有代碼的基礎上擴展系統的功能,達到開閉原則的要求。

      Sunny軟件公司開發的CRM系統能夠顯示各類類型的圖表,如餅狀圖和柱狀圖等,爲了支持多種圖表顯示方式,原始設計方案如圖1所示:

圖1 初始設計方案結構圖

      在ChartDisplay類的display()方法中存在以下代碼片斷:

 

      現對該系統進行重構,使之符合開閉原則。

       在本實例中,因爲在ChartDisplay類的display()方法中針對每個圖表類編程,所以增長新的圖表類不得不修改源代碼。能夠經過抽象化的方式對系統進行重構,使之增長新的圖表類時無須修改源代碼,知足開閉原則。具體作法以下:

      (1) 增長一個抽象圖表類AbstractChart,將各類具體圖表類做爲其子類;

      (2)  ChartDisplay類針對抽象圖表類進行編程,由客戶端來決定使用哪一種具體圖表。

      重構後結構如圖2所示:

圖2 重構後的結構圖

      在圖2中,咱們引入了抽象圖表類AbstractChart,且ChartDisplay針對抽象圖表類進行編程,並經過setChart()方法由客戶端來設置實例化的具體圖表對象,在ChartDisplay的display()方法中調用chart對象的display()方法顯示圖表。若是須要增長一種新的圖表,如折線圖LineChart,只須要將LineChart也做爲AbstractChart的子類,在客戶端向ChartDisplay中注入一個LineChart對象便可,無須修改現有類庫的源代碼。

       注意:由於xml和properties等格式的配置文件是純文本文件,能夠直接經過VI編輯器或記事本進行編輯,且無須編譯,所以在軟件開發中,通常不把對配置文件的修改認爲是對系統源代碼的修改。若是一個系統在擴展時只涉及到修改配置文件,而原有的Java代碼或C#代碼沒有作任何修改,該系統便可認爲是一個符合開閉原則的系統。

三.里氏替換原則

  里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士Barbara Liskov教授和卡內基·梅隆大學Jeannette Wing教授於1994年提出。其嚴格表述以下:若是對每個類型爲S的對象o1,都有類型爲T的對象o2,使得以T定義的全部程序P在全部的對象o1代換o2時,程序P的行爲沒有變化,那麼類型S是類型T的子類型。這個定義比較拗口且難以理解,所以咱們通常使用它的另外一個通俗版定義:

里氏代換原則(Liskov Substitution Principle, LSP):全部引用基類(父類)的地方必須能透明地使用其子類的對象。

      里氏代換原則告訴咱們,在軟件中將一個基類對象替換成它的子類對象,程序將不會產生任何錯誤和異常,反過來則不成立,若是一個軟件實體使用的是一個子類對象的話,那麼它不必定可以使用基類對象。例如:我喜歡動物,那我必定喜歡狗,由於狗是動物的子類;可是我喜歡狗,不能據此判定我喜歡動物,由於我並不喜歡老鼠,雖然它也是動物。

      例若有兩個類,一個類爲BaseClass,另外一個是SubClass類,而且SubClass類是BaseClass類的子類,那麼一個方法若是能夠接受一個BaseClass類型的基類對象base的話,如:method1(base),那麼它必然能夠接受一個BaseClass類型的子類對象sub,method1(sub)可以正常運行。反過來的代換不成立,如一個方法method2接受BaseClass類型的子類對象sub爲參數:method2(sub),那麼通常而言不能夠有method2(base),除非是重載方法。

      里氏代換原則是實現開閉原則的重要方式之一,因爲使用基類對象的地方均可以使用子類對象,所以在程序中儘可能使用基類類型來對對象進行定義,而在運行時再肯定其子類類型,用子類對象來替換父類對象

在使用里氏代換原則時須要注意以下幾個問題:

      (1)子類的全部方法必須在父類中聲明,或子類必須實現父類中聲明的全部方法。根據里氏代換原則,爲了保證系統的擴展性,在程序中一般使用父類來進行定義,若是一個方法只存在子類中,在父類中不提供相應的聲明,則沒法在以父類定義的對象中使用該方法。

      (2) 咱們在運用里氏代換原則時,儘可能把父類設計爲抽象類或者接口,讓子類繼承父類或實現父接口,並實如今父類中聲明的方法,運行時,子類實例替換父類實例,咱們能夠很方便地擴展系統的功能,同時無須修改原有子類的代碼,增長新的功能能夠經過增長一個新的子類來實現。里氏代換原則是開閉原則的具體實現手段之一。

      (3) Java語言中,在編譯階段,Java編譯器會檢查一個程序是否符合里氏代換原則,這是一個與實現無關的、純語法意義上的檢查,但Java編譯器的檢查是有侷限的。

      在Sunny軟件公司開發的CRM系統中,客戶(Customer)能夠分爲VIP客戶(VIPCustomer)和普通客戶(CommonCustomer)兩類,系統須要提供一個發送Email的功能,原始設計方案如圖1所示:

圖1原始結構圖

      在對系統進行進一步分析後發現,不管是普通客戶仍是VIP客戶,發送郵件的過程都是相同的,也就是說兩個send()方法中的代碼重複,並且在本系統中還將增長新類型的客戶。爲了讓系統具備更好的擴展性,同時減小代碼重複,使用里氏代換原則對其進行重構。

      在本實例中,能夠考慮增長一個新的抽象客戶類Customer,而將CommonCustomer和VIPCustomer類做爲其子類,郵件發送類EmailSender類針對抽象客戶類Customer編程,根據里氏代換原則,可以接受基類對象的地方必然可以接受子類對象,所以將EmailSender中的send()方法的參數類型改成Customer,若是須要增長新類型的客戶,只需將其做爲Customer類的子類便可。重構後的結構如圖2所示:

圖2  重構後的結構圖

里氏代換原則是實現開閉原則的重要方式之一。在本實例中,在傳遞參數時使用基類對象,除此之外,在定義成員變量、定義局部變量、肯定方法返回類型時均可使用里氏代換原則。針對基類編程,在程序運行時再肯定具體子類。

  另外補充一篇關於里氏替換原則的一篇博文:

四.依賴倒置原則

若是說開閉原則是面向對象設計的目標的話,那麼依賴倒轉原則就是面向對象設計的主要實現機制之一,它是系統抽象化的具體實現。依賴倒轉原則是Robert C. Martin在1996年爲「C++Reporter」所寫的專欄Engineering Notebook的第三篇,後來加入到他在2002年出版的經典著做「Agile Software Development, Principles, Patterns, and Practices」一書中。依賴倒轉原則定義以下:

依賴倒轉原則(Dependency Inversion  Principle, DIP):抽象不該該依賴於細節,細節應當依賴於抽象。換言之,要針對接口編程,而不是針對實現編程。

  依賴倒轉原則要求咱們在程序代碼中傳遞參數時或在關聯關係中,儘可能引用層次高的抽象層類,即便用接口和抽象類進行變量類型聲明、參數類型聲明、方法返回類型聲明,以及數據類型的轉換等,而不要用具體類來作這些事情。爲了確保該原則的應用,一個具體類應當只實現接口或抽象類中聲明過的方法,而不要給出多餘的方法,不然將沒法調用到在子類中增長的新方法。

      在引入抽象層後,系統將具備很好的靈活性,在程序中儘可能使用抽象層進行編程,而將具體類寫在配置文件中,這樣一來,若是系統行爲發生變化,只須要對抽象層進行擴展,並修改配置文件,而無須修改原有系統的源代碼,在不修改的狀況下來擴展系統的功能,知足開閉原則的要求。

      在實現依賴倒轉原則時,咱們須要針對抽象層編程,而將具體類的對象經過依賴注入(DependencyInjection, DI)的方式注入到其餘對象中,依賴注入是指當一個對象要與其餘對象發生依賴關係時,經過抽象來注入所依賴的對象。經常使用的注入方式有三種,分別是:構造注入,設值注入(Setter注入)和接口注入。構造注入是指經過構造函數來傳入具體類的對象,設值注入是指經過Setter方法來傳入具體類的對象,而接口注入是指經過在接口中聲明的業務方法來傳入具體類的對象。這些方法在定義時使用的是抽象類型,在運行時再傳入具體類型的對象,由子類對象來覆蓋父類對象。

      下面經過一個簡單實例來加深對依賴倒轉原則的理解:

      Sunny軟件公司開發人員在開發某CRM系統時發現:該系統常常須要將存儲在TXT或Excel文件中的客戶信息轉存到數據庫中,所以須要進行數據格式轉換。在客戶數據操做類中將調用數據格式轉換類的方法實現格式轉換和數據庫插入操做,初始設計方案結構如圖1所示:

圖1 初始設計方案結構圖

      在編碼實現圖1所示結構時,Sunny軟件公司開發人員發現該設計方案存在一個很是嚴重的問題,因爲每次轉換數據時數據來源不必定相同,所以須要更換數據轉換類,若有時候須要將TXTDataConvertor改成ExcelDataConvertor,此時,須要修改CustomerDAO的源代碼,並且在引入並使用新的數據轉換類時也不得不修改CustomerDAO的源代碼,系統擴展性較差,違反了開閉原則,現須要對該方案進行重構。

      在本實例中,因爲CustomerDAO針對具體數據轉換類編程,所以在增長新的數據轉換類或者更換數據轉換類時都不得不修改CustomerDAO的源代碼。咱們能夠經過引入抽象數據轉換類解決該問題,在引入抽象數據轉換類DataConvertor以後,CustomerDAO針對抽象類DataConvertor編程,而將具體數據轉換類名存儲在配置文件中,符合依賴倒轉原則。根據里氏代換原則,程序運行時,具體數據轉換類對象將替換DataConvertor類型的對象,程序不會出現任何問題。更換具體數據轉換類時無須修改源代碼,只須要修改配置文件;若是須要增長新的具體數據轉換類,只要將新增數據轉換類做爲DataConvertor的子類並修改配置文件便可,原有代碼無須作任何修改,知足開閉原則。重構後的結構如圖2所示:

圖2重構後的結構圖

 

      在上述重構過程當中,咱們使用了開閉原則、里氏代換原則和依賴倒轉原則,在大多數狀況下,這三個設計原則會同時出現,開閉原則是目標,里氏代換原則是基礎,依賴倒轉原則是手段,它們相輔相成,相互補充,目標一致,只是分析問題時所站角度不一樣而已。

五.接口隔離原則

  接口隔離原則定義以下:

接口隔離原則(Interface  Segregation Principle, ISP):使用多個專門的接口,而不使用單一的總接口,即客戶端不該該依賴那些它不須要的接口。

      根據接口隔離原則,當一個接口太大時,咱們須要將它分割成一些更細小的接口,使用該接口的客戶端僅需知道與之相關的方法便可。每個接口應該承擔一種相對獨立的角色,不幹不應乾的事,該乾的事都要幹。這裏的「接口」每每有兩種不一樣的含義:一種是指一個類型所具備的方法特徵的集合,僅僅是一種邏輯上的抽象;另一種是指某種語言具體的「接口」定義,有嚴格的定義和結構,好比Java語言中的interface。對於這兩種不一樣的含義,ISP的表達方式以及含義都有所不一樣:

      (1) 當把「接口」理解成一個類型所提供的全部方法特徵的集合的時候,這就是一種邏輯上的概念,接口的劃分將直接帶來類型的劃分。能夠把接口理解成角色,一個接口只能表明一個角色,每一個角色都有它特定的一個接口,此時,這個原則能夠叫作「角色隔離原則」。

      (2) 若是把「接口」理解成狹義的特定語言的接口,那麼ISP表達的意思是指接口僅僅提供客戶端須要的行爲,客戶端不須要的行爲則隱藏起來,應當爲客戶端提供儘量小的單獨的接口,而不要提供大的總接口。在面向對象編程語言中,實現一個接口就須要實現該接口中定義的全部方法,所以大的總接口使用起來不必定很方便,爲了使接口的職責單一,須要將大接口中的方法根據其職責不一樣分別放在不一樣的小接口中,以確保每一個接口使用起來都較爲方便,並都承擔某一單一角色。接口應該儘可能細化,同時接口中的方法應該儘可能少,每一個接口中只包含一個客戶端(如子模塊或業務邏輯類)所需的方法便可,這種機制也稱爲「定製服務」,即爲不一樣的客戶端提供寬窄不一樣的接口。

      下面經過一個簡單實例來加深對接口隔離原則的理解:

      Sunny軟件公司開發人員針對某CRM系統的客戶數據顯示模塊設計瞭如圖1所示接口,其中方法dataRead()用於從文件中讀取數據,方法transformToXML()用於將數據轉換成XML格式,方法createChart()用於建立圖表,方法displayChart()用於顯示圖表,方法createReport()用於建立文字報表,方法displayReport()用於顯示文字報表。

圖1 初始設計方案結構圖

      在實際使用過程當中發現該接口很不靈活,例如若是一個具體的數據顯示類無須進行數據轉換(源文件自己就是XML格式),但因爲實現了該接口,將不得不實現其中聲明的transformToXML()方法(至少須要提供一個空實現);若是須要建立和顯示圖表,除了需實現與圖表相關的方法外,還須要實現建立和顯示文字報表的方法,不然程序編譯時將報錯。

      現使用接口隔離原則對其進行重構。

      在圖1中,因爲在接口CustomerDataDisplay中定義了太多方法,即該接口承擔了太多職責,一方面致使該接口的實現類很龐大,在不一樣的實現類中都不得不實現接口中定義的全部方法,靈活性較差,若是出現大量的空方法,將致使系統中產生大量的無用代碼,影響代碼質量;另外一方面因爲客戶端針對大接口編程,將在必定程序上破壞程序的封裝性,客戶端看到了不該該看到的方法,沒有爲客戶端定製接口。所以須要將該接口按照接口隔離原則和單一職責原則進行重構,將其中的一些方法封裝在不一樣的小接口中,確保每個接口使用起來都較爲方便,並都承擔某一單一角色,每一個接口中只包含一個客戶端(如模塊或類)所需的方法便可。

      經過使用接口隔離原則,本實例重構後的結構如圖2所示:

圖2 重構後的結構圖

在使用接口隔離原則時,咱們須要注意控制接口的粒度,接口不能過小,若是過小會致使系統中接口氾濫,不利於維護;接口也不能太大,太大的接口將違背接口隔離原則,靈活性較差,使用起來很不方便。通常而言,接口中僅包含爲某一類用戶定製的方法便可,不該該強迫客戶依賴於那些它們不用的方法。

六.迪米特法則

  迪米特法則來自於1987年美國東北大學(Northeastern University)一個名爲「Demeter」的研究項目。迪米特法則又稱爲最少知識原則(LeastKnowledge Principle, LKP),其定義以下:

迪米特法則(Law of  Demeter, LoD):一個軟件實體應當儘量少地與其餘實體發生相互做用。

      若是一個系統符合迪米特法則,那麼當其中某一個模塊發生修改時,就會盡可能少地影響其餘模塊,擴展會相對容易,這是對軟件實體之間通訊的限制,迪米特法則要求限制軟件實體之間通訊的寬度和深度。迪米特法則可下降系統的耦合度,使類與類之間保持鬆散的耦合關係。

      迪米特法則還有幾種定義形式,包括不要和「陌生人」說話只與你的直接朋友通訊等,在迪米特法則中,對於一個對象,其朋友包括如下幾類:

      (1) 當前對象自己(this);

     (2) 以參數形式傳入到當前對象方法中的對象;

      (3) 當前對象的成員對象;

      (4) 若是當前對象的成員對象是一個集合,那麼集合中的元素也都是朋友;

      (5) 當前對象所建立的對象。

      任何一個對象,若是知足上面的條件之一,就是當前對象的「朋友」,不然就是「陌生人」。在應用迪米特法則時,一個對象只能與直接朋友發生交互,不要與「陌生人」發生直接交互,這樣作能夠下降系統的耦合度,一個對象的改變不會給太多其餘對象帶來影響。

      迪米特法則要求咱們在設計系統時,應該儘可能減小對象之間的交互,若是兩個對象之間沒必要彼此直接通訊,那麼這兩個對象就不該當發生任何直接的相互做用,若是其中的一個對象須要調用另外一個對象的某一個方法的話,能夠經過第三者轉發這個調用。簡言之,就是經過引入一個合理的第三者來下降現有對象之間的耦合度

      在將迪米特法則運用到系統設計中時,要注意下面的幾點:在類的劃分上,應當儘可能建立鬆耦合的類,類之間的耦合度越低,就越有利於複用,一個處在鬆耦合中的類一旦被修改,不會對關聯的類形成太大波及在類的結構設計上,每個類都應當儘可能下降其成員變量和成員函數的訪問權限在類的設計上,只要有可能,一個類型應當設計成不變類在對其餘類的引用上,一個對象對其餘對象的引用應當降到最低

      下面經過一個簡單實例來加深對迪米特法則的理解:

      Sunny軟件公司所開發CRM系統包含不少業務操做窗口,在這些窗口中,某些界面控件之間存在複雜的交互關係,一個控件事件的觸發將致使多個其餘界面控件產生響應,例如,當一個按鈕(Button)被單擊時,對應的列表框(List)、組合框(ComboBox)、文本框(TextBox)、文本標籤(Label)等都將發生改變,在初始設計方案中,界面控件之間的交互關係可簡化爲如圖1所示結構:

圖1 初始設計方案結構圖

      在圖1中,因爲界面控件之間的交互關係複雜,致使在該窗口中增長新的界面控件時須要修改與之交互的其餘控件的源代碼,系統擴展性較差,也不便於增長和刪除新控件。

      現使用迪米特對其進行重構。

      在本實例中,能夠經過引入一個專門用於控制界面控件交互的中間類(Mediator)來下降界面控件之間的耦合度。引入中間類以後,界面控件之間再也不發生直接引用,而是將請求先轉發給中間類,再由中間類來完成對其餘控件的調用。當須要增長或刪除新的控件時,只需修改中間類便可,無須修改新增控件或已有控件的源代碼,重構後結構如圖2所示:

圖2  重構後的結構圖

相關文章
相關標籤/搜索