極客時間-左耳聽風-程序員攻略-軟件設計

時間  2019-11-12
標籤 極客 時間 左耳 聽風 程序員 攻略 軟件 設計 欄目 快樂工作 简体版
原文   原文鏈接

程序員練級攻略：軟件設計

編程範式

學習編程範式可讓你明白編程的本質和各類語言的編程方式。所以，我推薦如下一些資料，以幫助你係統化地學習和理解。html

一些軟件設計的相關原則

  • Don’t Repeat Yourself (DRY) ，DRY 是一個最簡單的法則，也是最容易被理解的。但它也多是最難被應用的（由於要作到這樣，咱們須要在泛型設計上作至關的努力，這並非一件容易的事）。它意味着，當在兩個或多個地方發現一些類似代碼的時候，咱們須要把它們的共性抽象出來造成一個惟一的新方法，而且改變現有地方的代碼讓它們以一些合適的參數調用這個新的方法。git

  • Keep It Simple, Stupid(KISS) ，KISS 原則在設計上可能最被推崇，在家裝設計、界面設計和操做設計上，複雜的東西愈來愈被衆人所鄙視了，而簡單的東西愈來愈被人所承認。宜家（IKEA）簡約、高效的家居設計和生產思路；微軟（Microsoft）「所見即所得」的理念；谷歌（Google）簡約、直接的商業風格，無一例外地遵循了「KISS」原則。也正是「KISS」原則，成就了這些看似神奇的商業經典。而蘋果公司的 iPhone 和 iPad 將這個原則實踐到了極至。程序員

  • Program to an interface, not an implementation，這是設計模式中最根本的哲學，注重接口，而不是實現，依賴接口，而不是實現。接口是抽象是穩定的，實現則是多種多樣的。在面向對象的 S.O.L.I.D 原則中會提到咱們的依賴倒置原則，就是這個原則的另外一種樣子。還有一條原則叫 Composition over inheritance（喜歡組合而不是繼承），這兩條是那 23 個經典設計模式中的設計原則。github

  • You Ain’t Gonna Need It (YAGNI) ，這個原則簡而言之爲——只考慮和設計必須的功能，避免過分設計。只實現目前須要的功能，在之後你須要更多功能時，能夠再進行添加。如無必要，勿增複雜性。軟件開發是一場 trade-off 的博弈。數據庫

  • Law of Demeter，迪米特法則 (Law of Demeter)，又稱「最少知識原則」（Principle of Least Knowledge），其來源於 1987 年荷蘭大學的一個叫作 Demeter 的項目。克雷格·拉爾曼（Craig Larman）把 Law of Demeter 又稱做「不要和陌生人說話」。在《程序員修煉之道》中講 LoD 的那一章將其叫做「解耦合與迪米特法則」。編程

    關於迪米特法則有一些很形象的比喻：1) 若是你想讓你的狗跑的話，你會對狗狗說仍是對四條狗腿說？2) 若是你去店裏買東西，你會把錢交給店員，仍是會把錢包交給店員讓他本身拿？和狗的四肢說話？讓店員本身從錢包裏拿錢？這聽起來有點兒荒唐，不過在咱們的代碼裏這幾乎是見怪不怪的事情了。對於 LoD，正式的表述以下：設計模式

    對於對象 ‘O’ 中一個方法’M’，M 應該只可以訪問如下對象中的方法：api

    1. 對象 O；
    2. 與 O 直接相關的 Component Object；
    3. 由方法 M 建立或者實例化的對象；
    4. 做爲方法 M 的參數的對象。

  • 面向對象的 S.O.L.I.D 原則：服務器

    • SRP（Single Responsibility Principle）- 職責單一原則。關於單一職責原則，其核心的思想是：一個類，只作一件事，並把這件事作好，其只有一個引發它變化的緣由。單一職責原則能夠看做是低耦合、高內聚在面向對象原則上的引伸，將職責定義爲引發變化的緣由，以提升內聚性來減小引發變化的緣由。

    職責過多，可能引發它變化的緣由就越多，這將致使職責依賴，相互之間就產生影響，從而極大地損傷其內聚性和耦合度。單一職責，一般意味着單一的功能，所以不要爲一個模塊實現過多的功能點，以保證明體只有一個引發它變化的緣由。restful

    • OCP（Open/Closed Principle）- 開閉原則。關於開發封閉原則，其核心的思想是：模塊是可擴展的，而不可修改的。也就是說，對擴展是開放的，而對修改是封閉的。對擴展開放，意味着有新的需求或變化時，能夠對現有代碼進行擴展，以適應新的狀況。對修改封閉，意味着類一旦設計完成，就能夠獨立完成其工做，而不要對類進行任何修改。
    • LSP（Liskov substitution principle）- 里氏代換原則。軟件工程大師羅伯特·馬丁（Robert C. Martin）把里氏代換原則最終簡化爲一句話：「Subtypes must be substitutable for their base types」。也就是，子類必須可以替換成它們的基類。即子類應該能夠替換任何基類可以出現的地方，而且通過替換之後，代碼還能正常工做。另外，不該該在代碼中出現 if/else 之類對子類類型進行判斷的條件。里氏替換原則 LSP 是使代碼符合開閉原則的一個重要保證。正是因爲子類型的可替換性才使得父類型的模塊在無需修改的狀況下就能夠擴展。
    • ISP（Interface Segregation Principle ）- 接口隔離原則。接口隔離原則的意思是把功能實如今接口中，而不是類中，使用多個專門的接口比使用單一的總接口要好。舉個例子，咱們對電腦有不一樣的使用方式，好比：寫做、通信、看電影、打遊戲、上網、編程、計算和數據存儲等。

    若是咱們把這些功能都聲明在電腦的抽象類裏面，那麼，咱們的上網本、PC 機、服務器和筆記本的實現類都要實現全部的這些接口，這就顯得太複雜了。因此，咱們能夠把這些功能接口隔離開來，如工做學習接口、編程開發接口、上網娛樂接口、計算和數據服務接口，這樣，咱們的不一樣功能的電腦就能夠有所選擇地繼承這些接口。

    • DIP（Dependency Inversion Principle）- 依賴倒置原則。高層模塊不該該依賴於低層模塊的實現，而是依賴於高層抽象。舉個例子，牆面的開關不該該依賴於電燈的開關實現，而是應該依賴於一個抽象的開關的標準接口。這樣，當咱們擴展程序的時候，開關一樣能夠控制其它不一樣的燈，甚至不一樣的電器。也就是說，電燈和其它電器繼承並實現咱們的標準開關接口，而開關廠商就能夠不須要關於其要控制什麼樣的設備，只須要關心那個標準的開關標準。這就是依賴倒置原則。

  • CCP（Common Closure Principle） - 共同封閉原則，一個包中全部的類應該對同一種類型的變化關閉。一個變化影響一個包，便影響了包中全部的類。一個更簡短的說法是：一塊兒修改的類，應該組合在一塊兒（同一個包裏）。若是必須修改應用程序裏的代碼，那麼咱們但願全部的修改都發生在一個包裏（修改關閉），而不是遍及在不少包裏。

    CCP 原則就是把由於某個一樣的緣由而須要修改的全部類組合進一個包裏。若是兩個類從物理上或者從概念上聯繫得很是緊密，它們一般一塊兒發生改變，那麼它們應該屬於同一個包。CCP 延伸了開閉原則（OCP）的「關閉」概念，當由於某個緣由須要修改時，把須要修改的範圍限制在一個最小範圍內的包裏。

  • CRP（Common Reuse Principle）- 共同重用原則 ，包的全部類被一塊兒重用。若是你重用了其中的一個類，就重用所有。換個說法是，沒有被一塊兒重用的類不該該組合在一塊兒。CRP 原則幫助咱們決定哪些類應該被放到同一個包裏。依賴一個包就是依賴這個包所包含的一切。

    當一個包發生了改變，併發布新的版本，使用這個包的全部用戶都必須在新的包環境下驗證他們的工做，即便被他們使用的部分沒有發生任何改變。由於若是包中包含未被使用的類，即便用戶不關心該類是否改變，但用戶仍是不得不升級該包並對原來的功能加以從新測試。CCP 則讓系統的維護者受益。CCP 讓包儘量大（CCP 原則加入功能相關的類），CRP 則讓包儘量小（CRP 原則剔除不使用的類）。它們的出發點不同，但不相互衝突。

  • 好萊塢原則 - Hollywood Principle ，好萊塢原則就是一句話——「don’t call us, we’ll call you.」。意思是，好萊塢的經紀人不但願你去聯繫他們，而是他們會在須要的時候來聯繫你。也就是說，全部的組件都是被動的，全部的組件初始化和調用都由容器負責。

    簡單來說，就是由容器控制程序之間的關係，而非傳統實現中，由程序代碼直接操控。這也就是所謂「控制反轉」的概念所在：1) 不建立對象，而是描述建立對象的方式。2）在代碼中，對象與服務沒有直接聯繫，而是容器負責將這些聯繫在一塊兒。控制權由應用代碼中轉到了外部容器，控制權的轉移，是所謂反轉。好萊塢原則就是IoC（Inversion of Control） 或DI（Dependency Injection）的基礎原則。

  • 高內聚， 低耦合 & - High Cohesion & Low/Loose coupling，這個原則是 UNIX 操做系統設計的經典原則，把模塊間的耦合降到最低，而努力讓一個模塊作到精益求精。內聚，指一個模塊內各個元素彼此結合的緊密程度；耦合指一個軟件結構內不一樣模塊之間互連程度的度量。內聚意味着重用和獨立，耦合意味着多米諾效應牽一髮動全身。對於面向對象來講，你也能夠看看馬薩諸塞州戈登學院的面向對象課中的這一節講義High Cohesion and Low Coupling。

  • CoC（Convention over Configuration）- 慣例優於配置原則 ，簡單點說，就是將一些公認的配置方式和信息做爲內部缺省的規則來使用。例如，Hibernate 的映射文件，若是約定字段名和類屬性一致的話，基本上就能夠不要這個配置文件了。你的應用只須要指定不 convention 的信息便可，從而減小了大量 convention 而又不得不花時間和精力囉裏囉嗦的東東。

    配置文件在不少時候至關影響開發效率。Rails 中不多有配置文件（但不是沒有，數據庫鏈接就是一個配置文件）。Rails 的 fans 號稱其開發效率是 Java 開發的 10 倍，估計就是這個緣由。Maven 也使用了 CoC 原則，當你執行 mvn -compile命令的時候，不須要指定源文件放在什麼地方，而編譯之後的 class 文件放置在什麼地方也沒有指定，這就是 CoC 原則。

  • SoC (Separation of Concerns) - 關注點分離 ，SoC 是計算機科學中最重要的努力目標之一。這個原則，就是在軟件開發中，經過各類手段，將問題的各個關注點分開。若是一個問題能分解爲獨立且較小的問題，就是相對較易解決的。問題太過於複雜，要解決問題須要關注的點太多，而程序員的能力是有限的，不能同時關注於問題的各個方面。

    正如程序員的記憶力相對於計算機知識來講那麼有限同樣，程序員解決問題的能力相對於要解決的問題的複雜性也是同樣的很是有限。在咱們分析問題的時候，若是咱們把全部的東西混在一塊兒討論，那麼就只會有一個結果——亂。實現關注點分離的方法主要有兩種，一種是標準化，另外一種是抽象與包裝。標準化就是制定一套標準，讓使用者都遵照它，將人們的行爲統一塊兒來，這樣使用標準的人就不用擔憂別人會有不少種不一樣的實現，使本身的程序不能和別人的配合。

    就像是開發鏍絲釘的人只專一於開發鏍絲釘就好了，而不用關注鏍帽是怎麼生產的，反正鏍帽和鏍絲釘按照標準來就必定能合得上。不斷地把程序的某些部分抽象幷包裝起來，也是實現關注點分離的好方法。一旦一個函數被抽象出來並實現了，那麼使用函數的人就不用關心這個函數是如何實現的。一樣的，一旦一個類被抽象並實現了，類的使用者也不用再關注於這個類的內部是如何實現的。諸如組件、分層、面向服務等這些概念都是在不一樣的層次上作抽象和包裝，以使得使用者不用關心它的內部實現細節。

  • DbC（Design by Contract）- 契約式設計 ，DbC 的核心思想是對軟件系統中的元素之間相互合做以及「責任」與「義務」的比喻。這種比喻從商業活動中「客戶」與「供應商」達成「契約」而得來。若是在程序設計中一個模塊提供了某種功能，那麼它要：

    • 指望全部調用它的客戶模塊都保證必定的進入條件：這就是模塊的先驗條件（客戶的義務和供應商的權利，這樣它就不用去處理不知足先驗條件的狀況）。
    • 保證退出時給出特定的屬性：這就是模塊的後驗條件（供應商的義務，顯然也是客戶的權利）。
    • 在進入時假定，並在退出時保持一些特定的屬性：不變式。

  • ADP（Acyclic Dependencies Principle）- 無環依賴原則 ，包（或服務）之間的依賴結構必須是一個直接的無環圖形，也就是說，在依賴結構中不容許出現環（循環依賴）。若是包的依賴造成了環狀結構，怎麼樣打破這種循環依賴呢？

    有兩種方法能夠打破這種循環依賴關係：第一種方法是建立新的包，若是 A、B、C 造成環路依賴，那麼把這些共同類抽出來放在一個新的包 D 裏。這樣就把 C 依賴 A 變成了 C 依賴 D 以及 A 依賴 D，從而打破了循環依賴關係。第二種方法是使用 DIP（依賴倒置原則）和 ISP（接口分隔原則）設計原則。無環依賴原則（ADP）爲咱們解決包之間的關係耦合問題。在設計模塊時，不能有循環依賴。

一些軟件設計的讀物

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程