6.3 為什么要采用開閉原則 每個事物的誕生都有它存在的必要性，存在即合理，那開閉原則的存在也是合理的，為什么這么說呢？ 首先，開閉原則非常著名，只要是做面向對象編程的，甭管是什么語言，Java也好，C++也好，或者是Smalltalk，在開發時都會提及開閉原則。 其次，開閉原則是最基礎的一個原則，前五章節介紹的原則都是開閉原則的具體形態，也就是說前五個原則就是指導設計的工具和方法，而開閉原則才是其精神領袖。換一個角度來理解，依照Java語言的稱謂，開閉原則是抽象類，其他五大原則是具體的實現類，開閉原則在面向對象設計領域中的地位就類似于牛頓第一定律在力學、勾股定律在幾何學、質能方程在狹義相對論中的地位，其地位無人能及。 最后，開閉原則是非常重要的，可通過以下幾個方面來理解其重要性。 1. 開閉原則對測試的影響 所有已經投產的代碼都是有意義的，并且都受系統規則的約束，這樣的代碼都要經過“千錘百煉”的測試過程，不僅保證邏輯是正確的，還要保證苛刻條件（高壓力、異常、錯誤）下不產生“有毒代碼”（Poisonous Code），因此有變化提出時，我們就需要考慮一下，原有的健壯代碼是否可以不修改，僅僅通過擴展實現變化呢？否則，就需要把原有的測試過程回籠一遍，需要進行單元測試、功能測試、集成測試甚至是驗收測試，現在雖然在大力提倡自動化測試工具，但是仍然代替不了人工的測試工作。 以上面提到的書店售書為例，IBook接口寫完了，實現類NovelBook也寫好了，我們需要寫一個測試類進行測試，測試類如代碼清單6-6所示。 代碼清單6-6 小說類的單元測試 public?class?NovelBookTest?extends?TestCase?{ ?????private?String?name?=?"平凡的世界"; ?????private?int?price?=?6000; ?????private?String?author?=?"路遙";?????? ?????private?IBook?novelBook?=?new?NovelBook(name,price,author); ?????//測試getPrice方法 ?????public?void?testGetPrice()?{ ?????????????//原價銷售，根據輸入和輸出的值是否相等進行斷言 ?????????????super.assertEquals(this.price,?this.novelBook.getPrice()); ?????} } 單元測試通過，顯示綠條。在單元測試中，有一句非常有名的話，叫做"Keep the bar green to keep the code clean"，即保持綠條有利于代碼整潔，這是什么意思呢？綠條就是Junit運行的兩種結果中的一種：要么是紅條，單元測試失敗；要么是綠條，單元測試通過。一個方法的測試方法一般不少于3種，為什么呢？首先是正常的業務邏輯要保證測試到，其次是邊界條件要測試到，然后是異常要測試到，比較重要的方法的測試方法甚至有十多種，而且單元測試是對類的測試，類中的方法耦合是允許的，在這樣的條件下，如果再想著通過修改一個方法或多個方法代碼來完成變化，基本上就是癡人說夢，該類的所有測試方法都要重構，想象一下你在一堆你并不熟悉的代碼中進行重構時的感覺吧！ 在書店售書的例子中，增加了一個打折銷售的需求，如果我們直接修改getPrice方法來實現業務需求的變化，那就要修改單元測試類。想想看，我們舉的這個例子是非常簡單的，如果是一個復雜的邏輯，你的測試類就要修改得面目全非。還有，在實際的項目中，一個類一般只有一個測試類，其中可以有很多的測試方法，在一堆本來就很復雜的斷言中進行大量修改，難免會出現測試遺漏情況，這是項目經理很難容忍的事情。 所以，我們需要通過擴展來實現業務邏輯的變化，而不是修改。上面的例子中通過增加一個子類OffNovelBook來完成了業務需求的變化，這對測試有什么好處呢？我們重新生成一個測試文件OffNovelBookTest，然后對getPrice進行測試，單元測試是孤立測試，只要保證我提供的方法正確就成了，其他的我不管，OffNovelBookTest如代碼清單6-7所示。 代碼清單6-7 打折銷售的小說類單元測試 public?class?OffNovelBookTest?extends?TestCase?{??? ?????private?IBook?below40NovelBook?=?new?OffNovelBook("平凡的世界",3000,"路遙"); ?????private?IBook?above40NovelBook?=?new?OffNovelBook("平凡的世界",6000,"路遙");?????? ?????//測試低于40元的數據是否是打8折 ?????public?void?testGetPriceBelow40()?{ ?????????????super.assertEquals(2400,?this.below40NovelBook.getPrice()); ?????}?? ?????//測試大于40的書籍是否是打9折 ?????public?void?testGetPriceAbove40(){ ?????????????super.assertEquals(5400,?this.above40NovelBook.getPrice()); ?????} } 新增加的類，新增加的測試方法，只要保證新增加類是正確的就可以了。 2. 開閉原則可以提高復用性 在面向對象的設計中，所有的邏輯都是從原子邏輯組合而來的，而不是在一個類中獨立實現一個業務邏輯。只有這樣代碼才可以復用，粒度越小，被復用的可能性就越大。那為什么要復用呢？減少代碼量，避免相同的邏輯分散在多個角落，避免日后的維護人員為了修改一個微小的缺陷或增加新功能而要在整個項目中到處查找相關的代碼，然后發出對開發人員“極度失望”的感慨。那怎么才能提高復用率呢？縮小邏輯粒度，直到一個邏輯不可再拆分為止。 3. 開閉原則可以提高可維護性 一款軟件投產后，維護人員的工作不僅僅是對數據進行維護，還可能要對程序進行擴展，維護人員最樂意做的事情就是擴展一個類，而不是修改一個類，甭管原有的代碼寫得多么優秀還是多么糟糕，讓維護人員讀懂原有的代碼，然后再修改，是一件很痛苦的事情，不要讓他在原有的代碼海洋里游弋完畢后再修改，那是對維護人員的一種折磨和摧殘。 4. 面向對象開發的要求 萬物皆對象，我們需要把所有的事物都抽象成對象，然后針對對象進行操作，但是萬物皆運動，有運動就有變化，有變化就要有策略去應對，怎么快速應對呢？這就需要在設計之初考慮到所有可能變化的因素，然后留下接口，等待“可能”轉變為“現實”。