對於設計模式最近觀感的淺薄理解

      最近比較多翻閱設計模式，設計模式平時工做中，咱們可能會常常見到有，好比單例模式、觀察者模式、模板模式，構建者模式，像好比以前使用的線程池內部使用的命令模式等，看的模式越多，愈加發現其實就一點： 面向接口編程 或者 抽象編程。

        爲何須要這樣子呢，咱們平時開發關注的通常都是搬磚寫代碼，只要把它實現了就好，老闆想要的實現結果，過程它不關注，這個對於若是是初創的app或者工程來講，好維護，可是若是動輒幾十萬行代碼的大工程來講，是不就會出問題了呢。因爲我的設計經驗有限，引用有個作遊戲的小夥伴的說法我的以爲挺生動的，好比我遊戲中，有土地、草、樹木、石頭、房子、木板等，他們都有具體的特徵和不一樣的地方，若是存在10對象實體，了而對象的提供了5個接口函數，也就是，讀寫操做，在程序中出現了幾十次，這時，若是不要這個對象了，換成其餘，那你是否是要改幾十處地方，這個時候若是須要修改，那就動輒幾十上百個地方了，這個時候咱們想起了一個工廠模式來進行改造。new的對象你不用關心它裏面的具體實現，好比若是你用new出來的對象，可能帶有參數或者不帶參數，若是參數都改動的話，那幾十個new的地方是不會搞得你的很淡疼。因此這個也是我我的理解爲何使用工廠模式的理由之一。工廠模式其實還有個很重要的點，就是生產的產品能夠擁有共同的特性，好比這兒說土地、草、樹木等，咱們是不要把它顯示出來，雖然本人沒作過遊戲，可是咱們想象一個過程，他們在各自的實現類中好比可能有一、 圖片（設計給的圖片表明花、草、樹木）二、動做（好比是否會隨着風飄動的幅度，也就是動畫） 三、繪製顯示 （給予的圖片+動做繪製顯示），這兒說到3個方法咱們能夠抽象出這些物件的特有屬性，能夠抽象出產品的公共接口，給予外部調用，而系統其它調用者不須要考慮它的內部具體實現。

      再說說我的理解之單例模式， 我會想真的爲何我要使用單例模式，先不去教科書上說的，最直觀一點是，它直接判斷對象是否爲空，只new一個實例能夠重複使用，什麼樣場景咱們會用到單例，咱們android編程的小夥伴都知道，Http請求類、ImageLoader的調用基本都是會考慮用到單例模式，爲何呢，一開始我也是有點茫然，後來想到一點是，不少對象都要用到它而不想要不斷new對象形成資源浪費。若是回到現實中，我的想到好比一個部門的祕書，一個部門的祕書是不須要基本跟全部人都要大量的打交道處理一些事情，公司會不會給你一我的派一我的祕書給你去處理事情呢，這個不會吧，由於要成本啊，回到單例的話，這兒只是作個假設部門祕書通常一個就夠了，假設祕書是一個對象的話，咱們就只new一個，是不和使用單例模式有點像，就是不要浪費資源。而從計算機角度來看，就是節省咱們硬件資源的開支，這是其一，其二還有個點是，內部的實現咱們對它作封裝，不用管底層的實現。

       而像ImageLoader的實現也是使用到了單例模式，說到ImageLoader，它底層的實現算比較複雜的，比較多使用了構建者模式，就好比ImageLoader的建立其實咱們須要對ImageLoader的一個配置類作定性的初始化，若是這兒不使用單例模式，處處進行new的話，咱們處處會用到ImageLoaderConfiguration配置這個實例來建立ImageLoader，先不考慮資源浪費，就單代碼的冗餘度和維護度來看，挺難受的。ImageLoaderConfiguration使用的建立者模式的一個亮點是，它能夠承載配置不少參數，而不對外暴露裏面底層的實現方法，好比builder咱們能夠配置它使用什麼樣的緩存，什麼樣的加載圖片，網絡加載失敗後的圖片、緩存的大小，緩存的圖片文件名稱加密方法，使用哪一種緩存機制，是fifo仍是lifo等，線程的優先級別（這兒我的有點盲點），各類類型參數大量配置而不暴露給ImageLoader，Imageloader是須要調用ImageLoaderConfiguration在中間去進行實現整個圖片加載的過程，構建者的亮點我的理解就是在這兒。若是在認真看咱們的okhttp也是使用了有構建者模式，builder以後設置鏈接的超時時間，什麼請求方式等，是否能夠緩存，想象下咱們使用ImageLoader或Okhttp無非都是請求一個資源，這個是惟一的核心，可是若是在前面new了一大堆的對象A、B、C各類ImageLoader或OkHttp須要使用的配置參數，看起來這個代碼是不很冗餘，並且每次都這樣作，是不很難維護呢？

    再談起咱們常用的EventBus，EventBus使用了發佈者/訂閱者模式，或者說觀察者模式，我先還原一個須要使用的場景，好比我有A、B、C、D等，我有個消息中心須要對A、B、C、D等進行發佈消息，我怎麼發送到給它們呢。觀察者模式就是爲了解決這個問題的，首先咱們能夠對A、B、C等進行註冊，實際上是把它們的實例加入咱們的一個列隊集合中，這兒咱們最好使用一個線程安全的集合，避免同步的問題。等咱們須要發佈消息的時候，咱們發佈的消息會帶着一個對象的東西（是不是主線程），咱們去遍歷他們，使用咱們java的反射，而後獲得相關的帶有@Subscribe的註解的方法並獲取到註解的內含有是不是主線程仍是後臺線程的值，而後去在對應的線程去作相應的操做。

     設計模式本質我的理解是面向接口或者抽象類來作個抽象層，達到一個解耦的過程，讓代碼可以更好的維護。 稍微看多點代碼，和本身翻閱有些資料書上來看，咱們在設計代碼的時候，每每通常不想要被暴露的變量或者方法都使用protected或者private，想被繼承的使用protected。這兒說的屬於我的膚淺看法，總之是要達到對外界一種隔離的原則，想要暴露給外部的儘可能使用接口來進行。

        之前我的也是常常喜歡使用public 能夠達到直接使用的過程，這兒其實會形成自身業務的暴露。 如A類有成員a,而程序須要對a數據改變，而你提供一慣的個B類能夠訪問a成員的getter接口，B類在其自身對a修改，看上去沒什麼，實際上，就是類耦合，對a的修改是類A的職務，因爲習提供getter，致使了，在寫類B的時候錯誤地添加了修改業務，使類A內聚能力下降，程序逐步龐大必然會愈加明顯，真所謂牽一髮動全身，小程序確實是很難看出問題所在。