SOLID面向對象編程的5條原則是什麼

立體幾何圖形
訓練
1

SOLID是首字母縮寫詞,是指面向對象設計的五項原則(OOD或OOP)。 這些是開發人員可以用來創建易於管理,維護和擴展的軟件的準則。 了解這些概念將使您成為一名更好的開發人員,並幫助您避免軟件管理問題。 成為一名優秀的程序員意味著什麼?

任何具有軟件編程經驗的人都會根據他們的職業道路,使用判斷參數來判斷他人編寫的軟件代碼。

在我的職業生涯中,我認識了許多開發人員,並且已經看到數千行代碼,當我需要評估開發人員的技能時,我主要關注以下兩個因素:

  • 閱讀代碼簡單;
  • 他們的代碼隨著時間的推移工作和發展的可能性。

幸運的是,有一些基礎知識或原理可以使您更好地進行編碼。

首字母縮寫詞SOLID代表:
S:單一責任原則
O:開閉原理
L:Liskov替代原則
I:接口隔離原理
D:依賴倒置原則

讓我們開始研究第一個SOLID原則,即

單一責任原則

一個類(或模塊)應該只有一個改變,發展的理由。

概念本身非常簡單,但是要實現這種簡單性,實現路徑可能會非常複雜。 一個班級只有一個改變的理由。

但為什麼? 

為什麼只有一個更改理由如此重要?

例如,如果有兩個不同的更改原因,則可以想像兩個不同的團隊可以出於兩個不同的原因來處理同一代碼。 每個人都必須實現自己的解決方案,在使用編譯語言(例如C ++,C#或Java)的情況下,這可能導致模塊與其他團隊或應用程序的其他部分不兼容。

另一個示例,如果您使用的是解釋語言,則可能由於不同的原因必須重新測試同一類或模塊。 這意味著需要更多的工作,時間和精力進行質量控制。

識別類或模塊應具有的功能比僅查看檢查表來運行測試要復雜得多。 

但是,讓我們嘗試從較不技術的角度進行思考,即嘗試分析類或模塊的用戶,即誰將使用它。 我們必須始終牢記的一個基本方面是,我們開發的由特定模塊提供服務的應用程序或系統的用戶將是那些要求對其進行修改的用戶。 所服務的人員將要求更改課程或模塊。 

模塊及其用法的一些示例:

  • 維護模塊:用戶由數據庫管理員和軟件架構師組成。
  • 報告模塊:用戶由辦公室工作人員,會計師和生產人員組成。
  • 工資管理系統的付款計算模塊:用戶可以包括律師,經理和會計師。
  • 圖書館管理系統的文本搜索模塊:用戶可以由館員或圖書館本身的訪問者和客戶代表。

因此,如果第一步是在模塊中尋找扮演對話者角色的演員或演員,將個人與所有角色聯繫起來可能會很困難。 在小公司中,一個人可以扮演多個角色,而在大公司中,可以有多個人扮演一個角色。 

確定角色而不是人員或用戶似乎更合理。

所以:

  • 軟件系統的用戶定義更改的原因;
  • 職責是滿足特定參與者(即係統用戶)需求的一系列功能;
  • 在參與者之間,用戶成為必須滿足用戶需求的功能族的變化源;
  • 用戶需求的演變,指導功能的發展;

SOLID原則

讓我們看一些例子

假設我們有一個Book類,它封裝了一本書的概念及其功能。

課堂書籍{

    函數getTitle(){

        返回“一本好書”;

    }

    函數getAuthor(){

        返回“ Alessandro Baricco”;

    }

    函數下一頁(){

        // 下一頁

    }

    函數printCurrentPage(){

        回顯“當前頁面的內容”;

    }

}

這是很普通的課。 我們有一本書,全班可以給我們標題,他們可以給我們作者,他們可以繼續前進。 最後,它還能夠在屏幕上打印當前頁面。 

但是,有一個小問題。 

考慮參與管理Book對象的參與者,他們可能是誰? 

我們可以在這裡輕鬆想到​​兩個不同的參與者: 圖書管理 (作為 館員)和 數據提交機制 (例如我們希望如何向用戶交付內容:屏幕,圖形用戶界面,純文本用戶界面,也許是打印)。 

因此,我們有兩個截然不同的演員與全班互動。

簡而言之,該類介於以下兩者之間:

  • 與業務邏輯 
  • 演講 

這可能是一個問題,因為它違反了單一責任原則(SRP)。 

我們如何進行更改,如何改進此代碼以遵守單一責任原則?

看下面的代碼:

課堂書籍{

    函數getTitle(){

        返回“ Oceano Mare”;

    }

    函數getAuthor(){

        返回“ Alessandro Baricco”;

    }

    功能翻頁(){

        // 下一頁

    }

    函數getCurrentPage(){

        回顯“當前頁面的內容”;

    }

}

界面打印機{

    函數printPage($頁面);

}

StampaLibro類實現打印機{

    函數printPages($頁面){

        echo $頁面;

    }

}

 

HtmlPrinter類實現Printer {

    函數printPages($頁面){

        迴聲'。 $頁面。 ' ';

    }

}

這個非常簡單的示例說明瞭如何將演示文稿與業務邏輯分開,並且符合SRP,它在我們項目的靈活性方面具有很大的優勢。

讓我們看另一個例子:

與上面的示例類似的示例是對象可以保存和從演示中檢索自身的情況。

課堂書籍{

    函數getTitle(){

        返回“ Oceano Mare”;

    }

    函數getAuthor(){

        返回“ Alessandro Baricco”;

    }

    功能翻頁(){

        // 下一頁

    }

    函數getCurrentPage(){

        返回“當前頁面的內容”;

    }

    函數save(){

        $ filename ='/文件/'。 $ this-> getTitolo()。 '-'。 $ this-> getAuthor();

        file_put_contents($ filename,serialize($ this));

    }

}

和以前一樣,在這裡我們也可以識別不同的參與者,例如 圖書管理 (作為 館員)和 堅持不懈。 每當我們想要更改頁面的瀏覽方式時,我們都需要更改此類。 我們有幾種改變的原因。

課堂書籍{

    函數getTitle(){

        返回“ Oceano Mare”;

    }

    函數getAuthor(){

        返回“ Alessandro Baricco”;

    }

    功能翻頁(){

        // 下一頁

    }

    函數getCurrentPage(){

        返回“當前頁面的內容”;

    }

}

類SimpleFilePersistence {

    功能保存(Book $ book){

        $ filename ='/文件/'。 $ book-> getTitle()。 '-'。 $ book-> getAuthor();

        file_put_contents($文件名,序列化($ book));

    }

}

將持久性操作移至另一類將明顯地將職責分開,並且我們可以自由地交換持久性方法而不會影響Book類。 例如,實現DatabasePersistence類將很簡單,並且圍繞書本操作構建的業務邏輯不會改變。

繼續閱讀第二個原理打開/關閉->

1評論

發表評論

伊爾陀indirizzo電子郵件的非SARA pubblicato。 我坎比索諾obbligatori contrassegnati *

利斯科夫原理
訓練
Liskov替代原理,第三種SOLID原理

子類絕不能影響或更改父類的類型定義。 此原則的概念是由Barbara Liskov在1987年會議的主題演講中介紹的,隨後在1994年與Jannette Wing一起發表在一篇文章中。它們的原始定義是……

谷歌營銷趨勢
訓練
如何使用Google趨勢進行實時營銷

公司在2020年遇到的最大困難之一是了解哪些產品部門可以實現業務多元化:事實上,大多數工業部門都遭受了沉重打擊,這使得公司幾乎不可能滲透到這些領域,特別是作為一個新的參與者。 製造業很少...

商業智能策略
方法
成功商業智能的策略

為業務智能製定成功的戰略始於對目標的正確構想。 我們在下面看到一些基本點。 評估當前狀況低估這方面將是一個嚴重的錯誤。 評估當前狀況意味著分析流程,結構...