小菜學設計模式——開放封閉原則

    背景

    本文標題爲何叫小菜學習設計模式，緣由是本文內容主要是學習《大話設計模式》時的筆記摘要部分，固然，並非記錄書中小菜的學習過程，這個徹底沒有意義，而是指本人學習設計模式的成長之旅。

    真誠的但願本身可以從一名小菜成長爲一名大鳥！

    編寫的程序應該知足：

    1）可維護

    2）可擴展

    3）可複用

    4）夠靈活

    廢話少說，言歸正傳，設計模式原則之：開放封閉原則

    書面理解

    開放封閉原則：軟件實體（類、模塊、函數等等）應該能夠擴展，可是不能夠修改

    對於擴展是開放的，對於修改則是關閉的

    不管模塊是多麼的封閉，都會存在一些對之沒法封閉的變化。既然不能徹底封閉，設計人員必須對於他設計的模塊應該對哪一種變化封閉作出選擇。他必須猜想出最有可能發生發生變化的種類，而後構造抽象來隔離那些變化。

    實際開發過程當中是很難經過猜想來判斷哪些種類會發生變化的，可是咱們卻能夠在發生小變化時，就及早想辦法應對發生更大的變化的可能。也就是說，等到變化發生時當即採起行動。

    在咱們最初編寫代碼時，假設變化不會發生，當變化發生時，咱們就建立抽象來隔離之後發生的同類變化。

    面對需求，對程序的改動是經過增長新代碼進行的，而不是更改現有的代碼 。

    咱們但願的是在開發工做中展開不久就知道可發生的變化。查明可能發生變化所等待的時間越長，要建立正確的抽象就越困難。換句話說，若是在開發過程當中已經使用或者依賴這個接口的地方越多，一旦這個接口須要繼續變化時，繼續抽象這個接口會越困難。

    開發封閉原則是面向對象設計的核心之所在，遵循這個原則能夠帶來面向對象技術所聲稱的巨大好處。也就是可維護、可擴展、可複用，夠靈活。

    另外，開發人員應該僅對程序中呈現出頻繁變化的那部分作出抽象，然而，對於應用程序中的每一個部分都刻意地進行抽象一樣是一個很差的主意。拒毫不成熟的抽象和抽象自己一樣重要。

    我的的理解

    開放封閉原則是設計模式也是面向接口編程中最重要的一個原則，這種不能修改但能夠擴展的思想是後期項目的維護與升級很是有利的基礎。

    若是你是作第三方SDK的API提供者，那麼封閉開發原則顯得尤其重要，試想，當你的程序沒法知足客戶需求，客戶想要自定義程序的時候，若是你沒有提供自定義擴展程序，那會是多麼的尷尬。難道還要客戶反編譯你的代碼進行重寫嗎？也許由於這個，或許客戶會直接放棄使用這樣的SDK，尤爲如今開源SDK俯拾便是，一旦你的SDK不能對外擴張，那麼路天然不會很長。

    我的理解的開放封閉是：對外提供的接口，用戶若是須要自定義功能（擴展）時，能夠再不修改接口內部代碼的基礎上，經過新增代碼模塊來完成擴展的功能。因此面向接口編程以及面向對象的三大特徵（繼承、抽象、多條）顯得尤其重要。