[[174789]]

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

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

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

// 以下是偽代碼的形式，并不嚴謹 
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); 
    } 
}  

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

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

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

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

那么，首先我們想當然的改動一下代碼吧。

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ù)據(jù)項和狀態(tài)，更多的UI控件，他們之間有非常多的依賴關系，如果按這樣的寫法，你的每個方法里面的邏輯都會變得非常惡心，復雜。甚至，設置某個UI的狀態(tài)還需要依賴其他的數(shù)據(jù)項，你沒辦法，只能把無關的數(shù)據(jù)當參數(shù)傳入，就會變成這樣。

// ?。?！爆炸?。?！為什么頭像要關注其他的數(shù)據(jù)！?。?nbsp;
public void setAvatar(Bitmap avatarImage, String desc) { 
    mAvatar.setImage(avatarImage); 
    if (desc== null || desc.equals("")) { 
        mAvatar.setVisible(true); 
    } else { 
        mAvatar.setVisible(false); 
    } 
}  

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

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

接下來就簡單了。我們的代碼改成這樣：

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(); 
    } 
}  

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

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

• 點擊事件
• 系統(tǒng)回調
• 網(wǎng)絡請求回調
• 定時器，handler

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

后來，在我領悟到上面這個技巧后，我重構了一波，里面有個超級大的updateView方法，然后對每個View進行更新。

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

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

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

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

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

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

當你日后維護的時候，哪個View出問題了，你只要找到那一坨就好了，別的都不需要管。