首頁  >  文章  >  後端開發  >  常見設計原則實例詳解

常見設計原則實例詳解

零下一度
零下一度原創
2017-06-23 14:28:331577瀏覽

設計原則構成了設計模式賴以建構的基礎。透過遵循經過驗證的設計原則,自己的程式碼會變得更靈活、更有能力適應變化,而且可維護性更佳。

常見設計原則

  • 簡約原則(KISS)
    KISS原則的目標就是讓程式碼保持簡潔但不要過於簡陋,從而避免引入任何不必要但複雜度。

  • 不要重複自己(DRY)
    BRY原則但目的是透過將公用但部分抽離出來放在一個單獨的地方,從而避免重複系統中的任何部分。當然避免重複的不僅是程式碼,還包括業務邏輯。

  • 講述而不要詢問(Tell,Don't Ask)
    這個原則要求應該告訴物件您希望它們執行什麼動作,而不是詢問有關物件狀態的問題然後您自己決定希望執行什麼動作。這樣有助於匹配責任並避免類別之間的緊密耦合。

  • 您不需要它(YAGNI)
    該原則指的是只需要將應用程式必須的功能包含進來,而不要試圖添加任何其他您認為可能需要的功能。

  • 分離關注點(SoC)
    SoC這個過程將軟體分解為多項不同的功能,每項功能封裝了可供其他類別使用的唯一行為和數據。通常,一個關注點代表類別的一項功能或行為。將程式劃分成若干獨立職責的做法顯著提高了程式碼的重用成都、維護性和可測試性。

S.O.L.I.D設計原則

  • #單一職責原則(SRP)
    SRP與分離關注原則保持高度一致。它要求每個物件應該有且只有一個職責關注點,即只有一個引起類別變化的原因。

  • 開放封閉原則(OCP)
    該原則要求類別對於擴展應該是開放的,而對於修改應該是關閉的,這樣應該就能夠在不改變類別的內部行為的情況下為類別添加新功能,並且避免類別被破壞,造成不必要的錯誤或則bug。

  • 里氏替換原則(LSP)
    任何父類別都應該可以被子類別替代,並且保持其行為不變。改原則與OCP原則保持一致,確保繼承類別不會影響父類別的行為。

  • 介面分離原則(ISP)
    ISP原則關注的是將介面方法依職責分割為若干個群組,並且為這些分組指派不同的介面。避免客戶端實現一個龐大和一堆用不到的介面。

  • 依賴倒置原則(DIP)
    DIP原則的宗旨是將自己寫的類別與具體的實作隔離開來,讓這些類別依賴抽像或介面。它提倡面向介面編程,這確保程式碼不會與某種實現緊密耦合,從而提高惡系統的靈活性。

  • 依賴注入(DI)與控制反轉(SoC)原則
    DI、SoC與DIP是緊密相連的。 DI透過建構器、方法或屬性提供低層類別或從屬類別。配合使用DI原則,這些從屬類可以反轉為介面或抽象類,這樣就可以形成一個具有較高的可測試性和易於修改的低耦合系統。

ASP.NET設計模式:

以上是常見設計原則實例詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章!

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