話說距離上次發文章已經是時隔將近乙個半月了，期間忙著專案所以對於文章或者說知識的總結就給忽略了！
這次我們來說說重構，說之前要感謝帶領我入門的那些大哥(我曾經的同事，我喊他鋒哥，還有經理 包大哥)，那個時候雖然大家都在討論但是我作為乙個菜鳥級的人物，聽得不太懂不過現在做android 這一塊我發現**真是亂，所以就想到了這個東西，於是乎就做了一把refactor!
個人理解重構的概念
以上是我個人的理解，有誤之處請大家指出來啊！無噴！
那麼好了接下來說例子，因為我做的android 專案現在負責的就是xml解析資料 以及返回給 activity 資料 先來了解一下結構類圖如下：
[img]
這是 原來沒有重構之前的類圖，需要說明的是service 和handler的子類有很多個！
下面說一下service 和 handler 裡面的方法。。。
在每個service 和 handler 裡面都包含有這樣乙個方法get***tbean()：object 返回的都是 具體的型別。。。(我這到這樣做不好)
下面我們重點說一下 service 裡面的方法。。
[img]
**如下：
public static checkoutbean getcheckoutbean(context context,string playlistid,string pid) throws parserconfigurationexception, saxexception, ioexception
return null;
}
public static checkuserplayingbean getcheckuserplayingbean(context context,string playlistid) throws parserconfigurationexception, saxexception, ioexception
return null;
}
注意比較上面兩段**，他們是否存在共同之處呢？
/*********以上是重構之前的**和結構*********************************************/
現在總結一下：我們從上面的圖 和 **中應該能察覺到這寫個handler 子類 以及 service 類中存在相同的**！ 而且他們在service處理 拿到物件的邏輯是相同的。。。
所以我在做完這一期專案之後就考慮了一下進行重構一把(不過千萬別忘了單元測試。。。如果重構之後沒有做測試，那麼我覺得你的工作只能說做了40%)！
那好接下來說說我重構的思路。。。。
因為service中存在專案的方法 和邏輯我想了一下就是準備使用模板方法 模式來進行重構！
他們出來物件的邏輯是相同的。因此我就有了這樣個 baseservice
沒有baseservice之前我們的處理方式就如同上面的那種。。。（getcheckoutbean（） getcheckuserplayingbean（）） 但是他們的程式邏輯是一樣的。
都是先拿到url 然後 交給httpclient類產生inputstream 之後就是判斷是否為空，接著就是
產生handler 讓後讓handler解析，最後就是拿到 handler 處理之後的物件！
現在我們看看baseservice 的tempalte 方法。。final 的防止子類修改 整個處理邏輯！
是的吧，是和原來一樣的邏輯！沒錯，你是對的，就是這樣的。。。然後讓所有的service子類都去繼承 這個baseservice 。。。。
注意你看到了。。在baseservice中包含了。。mydefaulthandler物件。。。。這裡之所以這麼做，是因為。。每乙個 handler 之類在解析完之後都會產生具體的 物件。。
如果是 playinglistbeanhandler 就產生。。。playinglistbean物件。。。如果是
checkoutbeanhandler 就產生。。checkoutbean ..。。看原來的類圖中。。可以看到這些方法。。的。。。
所以我就想這些物件都是 object的子類。。為何不能定義乙個通用的方法。。返回object 然後具體的型別都交給 呼叫類來轉換。。。
this.object = handler.getbean(); //就是這一句了。。呵呵。。
來看看。。mydefaulthandler 。。
public abstract class mydefaulthandler extends defaulthandler
只有這樣乙個方法。。。。abstract 來修飾的。。呵呵！！！
看重構之後的類圖：
[img]
接下來看重構之後的service**：
private string playlistid;
private string pid;
public parsercheckoutservice(){}
public parsercheckoutservice(
context context,string playlistid,string pid)
@override
protected string loadurl()
@override
protected mydefaulthandler gethandler()
public checkoutbean getcheckoutbean()
好了。。看看是不是比之前的** 清晰了。。。要是再有需求來了。。我就寫乙個service 繼承。。basservice 。。。然後程式邏輯不需要改變。。。也沒必要知道 是怎麼寫的。。
直接實現方法。。就可以了。。呵呵。。。應該說達到了。。**的復用！
對了。。我們來看一下鉤子函式的 。。呼叫**
當你需要呼叫。。如下**的時候。。
if(callback())
try catch (interruptedexception e)
retrytimes --;}}
你只需要讓 baseservice 重寫這個。。callback方法即可。。
@override
protected boolean callback()
、。。。這樣是不是感覺。。**清晰很多了呢！！！ 這裡我要感謝一下現在的同事，我最初重構的效果並非如此，要感謝他的建議！！！呵呵。。。
Android 重構歷程（一）
1.今天開始重構的第一步，就發現程式有問題了，原來，android 在5.0以下整個應用的方法數不可以超過65535，解決的方法有兩個，乙個是動態載入apk，還有乙個是分包。1 首先解決白屏問題，當在android studio設定分包，如下配置 在build gradle中 defaultconf...
專案重構實踐 一
size medium 經典重構的書籍已經敘述了很多需要重構的事情，但是很多時候書籍規書籍，實踐規實踐，到底搞清楚沒有，還是實際專案中來得實在，真實。真實專案重構 重構一 專案中把很多前期看起來差不多的邏輯，比如處理流程相同，資料具有相似性，剛開始寫action，把這些全部都寫在乙個action裡面...
重構與模式（一）
重構就是一種 保持行為的轉換 是一種對軟體內部結構的改善，目的是在不改變軟體的可見行為的情況下，使其更容易理解，修改的成本更低 重構過程包括去處重複，簡化複雜邏輯和澄清模糊的 重構是，需要對 的無情針砭，以改進其設計。這種改進可能很小，比如只是乙個變數名，也可能很大比如合併類。重構的動機，比較具有普...