面向對象設計原則概述
一說到面對對象的設計原則, 我就有點腦袋大, 向來就不擅長這個文字性的理解, 但是這些思維卻很重要, 首先, 就是面試離不來, 總是會被問道, 這個直接影響到你的錢包的後端, 這不得不看看了, 大家都跟錢沒仇吧, (嘿嘿),
其次, 這個在思想上很重要, 為什麼呢? 我們在寫代碼的時候, 應該是先設計好架構, 分析好邏輯, 應該用什麼方法, 最後的一步才是我們去寫代碼.
最後, 如果你去看一些源碼的時候, 很多時候就是都會跟你扯設計原則, 設計模式, 我當時就是臉的懵逼樣, 就想問問老天, 誰能告訴我, 好下面, 我們就來看看七大設計原則
對於面向對象軟件系統的設計而言, 在支持可維護性的同時, 提高系統的可複用性是一個至關重要的問題, 如何同時提高一個軟件系統的可維護性和可複用性是面對對象設計需要解決的核心問題之一, 在面向對象設計中, 可維護性的複用是以設計原則為基礎的. 每一個原則都蘊含一些面向對象設計的思想, 可以從不同的角度提升一個軟件結構的設計水平
對向對象設計原則為支持可維護性複用而誕生, 這些原則蘊含在很多設計模式中, 他們從很多設計方案中總結出的指導性原則, 面向對象設計原則也是我們用於評價一個設計模式的使用效果的重要指標之一, 在設計模式的學習中, 大家經常會看到諸如 "xxx模式符合XXX原則", "XXX模式違反了XXX原則"這樣的語句.
最常見的7種面向對象設計原則如下表所示:
設計原則名稱定義單一職責原則(Single Responsibility Principle, SRP)一個類只負責一個功能領域中的相應職責開閉原則(Open-Closed Principle, OCP)軟件實體應對擴展開放, 而對修改關閉里氏代換原則(Liskov Substitution Principle, LSP)所有引用基類對象的地方能夠透明地使用其子類的對象依賴倒轉原則(Dependence Inversion Principle, DIP)抽象不應該依賴於細節, 細節應該依賴於抽象接口隔離原則(Intereface Segreation Principle, ISP)使用多個專門的接口, 而不是用單一的總接口合成複用原則(Composite Reuse Principle, CRP)儘量使用對象組合, 而不是繼承來達到複用的目的迪米特法則(Law of Demeter, LOD)一個軟件實體應當儘可能少的與其他實體發生相互作用
面向對象七大設計原則
1. 單一職責原則
單一原則個人認為, 就是在設計之初, 就是把不同功能的類進行區分, 不同類的功能進行劃分, 越小越細緻越好, 這樣我們在對待不同的功能, 不能的作用, 劃分不同的類,
舉個很簡單的例子: 我們在使用sonar掃描的時候, 推薦使用sonarLint插件, 如果你的一個方法超過15行, 就會提示你方法太大, 算一個代碼異味, 就是要把我們方法進行拆分, 越細越好, 方法的行數不要超過15行, 這個也是<>的要求.這個僅僅是對方法的一個要求, 那對於我們的類進行設計呢, 功能劃分上要加要細緻, 要比方法這個更加細緻一些.
單一職責原則是最簡單的面向對象設計原則, 它用於控制類的粒度大小, 單一職責原則定義如下:
<code>單一職責原則(sINGLE Responsibility Principle, SRP): 一個類只負責一個功能領域中的相應職責, 或者可以定義為: 就一個類而言, 應該只有一個引起它變化的原因./<code>
單一職責原則告訴我們:一個類不能太“累”!在軟件系統中，一個類(大到模塊，小到方法)承擔的職責越多，它被複用的可能性就越小，而且一個類承擔的職責過多，就相當於將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責總是同時發生改變則可將它們封裝在同一類中。
單一職責原則是實現 的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責 並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。
舉例: 我們在java開發過程中, 經常使用到各個層, 比如: controller層, service層, manager層, dao層, mapper層, 等等這些, 其實這個層上的劃分, 就符合我們的單一原則, 不同的層, 不同, 做不同的事情,
比如我們做devops後臺的開發, jira, sonar, gitlab, 這些, 這些很自然的, 你就需要設計不同的controller, 下面的層依次劃分, 跟著站隊就好了!
有沒有get到.就是這麼簡單.
2. 開閉原則
開閉原則是面向對象的可服用設計的第一塊基石, 它是最重要的面向對象設計原則, 開閉原則由Bertrand meyer於1988年提出, 其定義如下:
<code>開閉原則(Open-Closed Principle, OCP): 一個軟件實體應當對擴展開發, 對修改關閉, 即軟件實體應該儘量在不能修改原有代碼的情況下進行擴展/<code>
在開閉原則的定義中， 。
<code>任何軟件都需要面臨一個很重要的問題，即它們的需求會隨時間的推移而發生變化。當軟件系統需要面對新的需求
時，我們應該儘量保證系統的設計框架是穩定的。如果一個軟件設計符合開閉原則，那麼可以非常方便地對系統進行
擴展，而且在擴展時無須修改現有代碼，使得軟件系統在擁有適應性和靈活性的同時具備較好的穩定性和延續性。隨
著軟件規模越來越大，軟件壽命越來越長，軟件維護成本越來越高，設計滿足開閉原則的軟件系統也變得越來越重
要。/<code>
為了滿足開閉原則，需要對系統進行抽象化設計，抽象化是開閉原則的關鍵 。在Java、C#等編程語言中，可以為系 統定義一個相對穩定的抽象層，而將不同的實現行為移至具體的實現層中完成。在很多面向對象編程語言中都提供了 接口、抽象類等機制，可以通過它們定義系統的抽象層，再通過具體類來進行擴展。如果需要修改系統的行為，無須 對抽象層進行任何改動，只需要增加新的具體類來實現新的業務功能即可，實現在不修改已有代碼的基礎上擴展系統 的功能，達到開閉原則的要求。
閱讀更多 故事凌 的文章
