[[174789]]

之前有段時(shí)間寫Windows桌面程序悟出的道理。

是這樣的，有時(shí)候，我們需要?jiǎng)?chuàng)建一個(gè)符合業(yè)務(wù)的View，或者稱為UI對(duì)象，比如，即時(shí)通訊軟件的好友列表里面的每個(gè)item，那么這個(gè)item要有頭像，名字，簡(jiǎn)短描述三個(gè)數(shù)據(jù)項(xiàng)。那么，我們這個(gè)View對(duì)象，就得有三個(gè)對(duì)應(yīng)的方法來設(shè)置這三個(gè)屬性，然后View顯示的時(shí)候，就顯示出我們***的數(shù)據(jù)就好了。

最最最開始的時(shí)候，我都是耿直的寫成這樣。

// 以下是偽代碼的形式，并不嚴(yán)謹(jǐn) 
class UserItemView extends View { 
    ImageView mAvatar; 
    TextView mName; 
    TextView mDesc; 
     
    public void setAvatar(Bitmap avatarImage) { 
        mAvatar.setImage(avatarImage); 
    } 
     
    public void setName(String name) { 
        mName.setText(name); 
    } 
     
    public void setDesc(String desc) { 
        mDesc.setText(desc); 
    } 
}  

在最開始的時(shí)候，這樣是OK的，看起來非常***，沒有任何問題。如果某個(gè)用戶的數(shù)據(jù)變了，就更新某個(gè)數(shù)據(jù)就好了。

好，現(xiàn)在問題了，這樣寫的問題在于，當(dāng)狀態(tài)/數(shù)據(jù)之間相互依賴對(duì)UI的顯示產(chǎn)生影響時(shí)，那么就會(huì)出問題，代碼會(huì)混亂。

我們現(xiàn)在提個(gè)這樣的需求，如果描述(desc)是空的，就顯示出頭像，如果不是空的，就不顯示頭像。

需求確實(shí)很奇怪，但是實(shí)際的工作中一定會(huì)遇到類似的情況。

那么，首先我們想當(dāng)然的改動(dòng)一下代碼吧。

class UserItemView extends View { 
    ImageView mAvatar; 
    TextView mName; 
    TextView mDesc; 
     
    String mDescData; 
     
    public void setAvatar(Bitmap avatarImage) { 
        mAvatar.setImage(avatarImage); 
    } 
     
    public void setName(String name) { 
        mName.setText(name); 
    } 
     
    public void setDesc(String desc) { 
        mDescData = desc; 
        if (mDescData == null || mDescData .equals("")) { 
            mAvatar.setVisible(true); 
        } else { 
            mAvatar.setVisible(false); 
        } 
        mDesc.setText(mDescData ); 
    } 
}  

你看，現(xiàn)在設(shè)置描述的方法里要去管頭像的顯示情況，這就很惡心了。如果有更多的數(shù)據(jù)項(xiàng)和狀態(tài)，更多的UI控件，他們之間有非常多的依賴關(guān)系，如果按這樣的寫法，你的每個(gè)方法里面的邏輯都會(huì)變得非常惡心，復(fù)雜。甚至，設(shè)置某個(gè)UI的狀態(tài)還需要依賴其他的數(shù)據(jù)項(xiàng)，你沒辦法，只能把無關(guān)的數(shù)據(jù)當(dāng)參數(shù)傳入，就會(huì)變成這樣。

// ?。?！爆炸?。。槭裁搭^像要關(guān)注其他的數(shù)據(jù)?。?！ 
public void setAvatar(Bitmap avatarImage, String desc) { 
    mAvatar.setImage(avatarImage); 
    if (desc== null || desc.equals("")) { 
        mAvatar.setVisible(true); 
    } else { 
        mAvatar.setVisible(false); 
    } 
}  

當(dāng)時(shí)，我那個(gè)UI已經(jīng)變得非常惡心了，在這樣的情況下，我終于意識(shí)到，對(duì)UI對(duì)象的更新，不能就地去做，UI對(duì)象的更新，應(yīng)該用一個(gè)統(tǒng)一的方法來做，而會(huì)改變UI顯示情況的那些setXXXX方法，只做兩件事，一是把數(shù)據(jù)設(shè)到這個(gè)對(duì)象的成員屬性上，另一件事就是調(diào)用統(tǒng)一的方法來更新UI。

其實(shí)一個(gè)標(biāo)準(zhǔn)的設(shè)計(jì)一直在眼前，直到那一刻，我才意識(shí)到和真正的理解。那就是Android中的View。Android中的每個(gè)View的子類，都有超級(jí)多的set方法，比如TextView，就有setText，setTextColor等等。它就是每個(gè)set方法，實(shí)際上是給這個(gè)對(duì)象做一個(gè)數(shù)據(jù)上的變化，然后就不管了。等到系統(tǒng)來調(diào)用OnDraw方法的時(shí)候，在OnDraw方法中統(tǒng)一的來更新UI。

接下來就簡(jiǎn)單了。我們的代碼改成這樣：

class UserItemView extends View { 
    ImageView mAvatar; 
    TextView mName; 
    TextView mDesc; 
     
    String mNameData; 
    String mDescData; 
    Bitmap mAvatarData; 
     
    public void updateView() { 
        mAvatar.setImage(mAvatarData); 
        if (mDescData== null || mDescData.equals("")) { 
            mAvatar.setVisible(true); 
        } else { 
            mAvatar.setVisible(false); 
        } 
         
        mDesc.setText(mDescData); 
         
        mName.setText(mNameData); 
    } 
     
    public void setAvatar(Bitmap avatarImage) { 
        mAvatarData = avatarImage; 
        updateView(); 
    } 
     
    public void setName(String name) { 
        mNameData = name; 
        updateView(); 
    } 
     
    public void setDesc(String desc) { 
        mDescData = desc; 
        updateView(); 
    } 
}  

注意到，添加了一個(gè)updateView方法，這個(gè)方法專門用來將數(shù)據(jù)更新到UI上，這樣寫，其他set方法一律只做把數(shù)據(jù)存進(jìn)來的事情，updateView方法專門根據(jù)當(dāng)前的數(shù)據(jù)狀態(tài)更新UI，這樣set方法就干凈整潔。而邏輯再?gòu)?fù)雜的顯示邏輯，都不用怕，在updateView里面搞就行了。

我曾經(jīng)并且一直在維護(hù)的一個(gè)Activity，它大概有15+個(gè)View，20-30個(gè)數(shù)據(jù)和狀態(tài)，這些數(shù)據(jù)和狀態(tài)會(huì)謎一般的印象著這些view的顯示。當(dāng)時(shí)年輕不懂事，就耿直的在數(shù)據(jù)變化的后面(下一行)，立馬就更新UI的狀態(tài)。有如下這些位置吧：

• 點(diǎn)擊事件
• 系統(tǒng)回調(diào)
• 網(wǎng)絡(luò)請(qǐng)求回調(diào)
• 定時(shí)器，handler

這么多地方都在更新數(shù)據(jù)，并且改變UI，維護(hù)起來簡(jiǎn)直要屎。

后來，在我領(lǐng)悟到上面這個(gè)技巧后，我重構(gòu)了一波，里面有個(gè)超級(jí)大的updateView方法，然后對(duì)每個(gè)View進(jìn)行更新。

這里有另一個(gè)小技巧，就是你有1w個(gè)View，和1w個(gè)狀態(tài)，你按狀態(tài)分類寫，還是按View分類寫。這個(gè)意思就是：按正常人思維吧，比如你的頁(yè)面有兩種模式，一般人就會(huì)寫

if (mode == A) { 
    viewA.xxxxxx 
    viewB.xxxxxx 
    ... 
} else if (mode == B) { 
    viewA.xxxxxx 
    viewB.xxxxxx 
    ... 
}  

這樣寫又出問題了，少年，你以為你的狀態(tài)只有兩種嗎?你以為每個(gè)UI對(duì)象，就只依賴一個(gè)狀態(tài)嗎?會(huì)這么優(yōu)雅的剛好分布在if和else里面嗎?你錯(cuò)了，需求這個(gè)東西啊，是非常惡心的，完全不符合邏輯的。

這樣寫呢，當(dāng)你狀態(tài)很多很多的時(shí)候，你很難去安排這個(gè)view的更新放哪里，如果有新加的狀態(tài)又影響到它。為了不影響到之前的邏輯，你往往就是再后面再加上一行，這樣多了也是難以維護(hù)的。

那樣怎么做呢?最簡(jiǎn)單，按View來分類寫。你有1w個(gè)View吧，那就挨個(gè)挨個(gè)來，先把***個(gè)View處理好了，***個(gè)View受那些影響呢?全部寫出來，if-else也好，什么都好，反正最開始這幾行代碼，先把View1搞定。

然后再一次寫View2，View3的邏輯，這樣唯一的缺點(diǎn)就是，你的判斷得重復(fù)寫?？瓷先ズ芾圪?，view1和view2，很可能他們的顯示邏輯是相同的，你非常想把他們寫在一個(gè)if-else里，但是我建議你不要這么做，為了***的變通性，請(qǐng)將他們分開寫。

當(dāng)你日后維護(hù)的時(shí)候，哪個(gè)View出問題了，你只要找到那一坨就好了，別的都不需要管。