关于通常界面程序的一些想法

不少时候，咱们去写东西的时候，都是闷头写，写到哪算哪，知道一些重构技巧的同窗可能会在边写的时候遇到重复就提取出来成方法这样，但这样一开始是蛮好的，由于你本身写的东西，你都知道，可是写久了，你回头一看，卧槽，怎么这么多小方法？！时间久了，你再回来定位问题的时候，你就会发现方法太多，致使了一个很重要的问题就是，调用层次很混乱，你很难找到你想要的那个方法，总之就这个意思，有遇到这个问题的，天然内心有所体会。

我举个例子，好比说，产品需求让咱们点下一个按钮，就发个网络请求，而后让UI显示“请求中”，数据回来的时候，再显示正确的UI。好，那么应该是这样的：

void onClick(View v) {
    switch (v.getId()) {
        case myButtonId:
            requestData();
            mButton.setText("请求中");
            break;
    }
}

void requestData() {
    // ...
}

void onRequestCallback(Data data) {
    // 回调来了，更新UI
    mButton.setText(data.toString());
}

首先，这样写是有问题的，我上一篇文章已经说过这样的问题了。问题在于就地去更新UI了。咱们要用一个统一的地方来更新UI，因而这个要改写成：

Data mData = null;
boolean mIsRequesting = false;

void onClick(View v) {
    switch (v.getId()) {
        case myButtonId:
            requestData();
            break;
    }
}

void requestData() {
    mIsRequesting = true;
    // 发起请求
    updateView()    
}

void onRequestCallback(Data data) {
    // 回调来了，更新UI
    mIsRequesting = false;
    mData = data;
    updateView();
}

// 用统一的方法更新UI，而且按照View分类
void updateView() {
    if (mIsRequesting) {
        mButton.setText("请求中");
    } else {
        if (mData != null) {
            mButton.setText(data.toString());
        }
    }
}

用统一的方法去更新UI，这个说法是很通俗的，我想谁均可以听明白吧，其实这个事情，是能够更加抽象的，也就是说，它能够是一种抽象，适应别的状况，最近我恰好又作了一些重构的工做，已经成功领悟到这个抽象，那就是：一个方法只去作一件事情，更准确的说，只作一类事情，或者说，一类事情只丢到一个方法里去作。不知道这样说，你们听明白没有。

说一个Android里面的范本吧。想一想onMeasure，onLayout，onDraw方法，单看onDraw方法，就是我上次说到的用统一的方法去更新UI，你三个方法一块儿看，你就明白了，一个方法只作一类事情，一类事情只丢到一个方法里去作。

onLayout里面须要的数据，都在onMeasure里去作好了，存到成员变量上，onLayout直接用，onDraw须要的东西，前两个步骤都作好了，onDraw直接用成员变量上的东西。换句话说，UI只关心它要展现的数据源，而不关心数据源的改变。

UI上的代码，至始至终都是直接拿着数据源来搞，而逻辑，改变数据源后，不要就地去更新UI，而应该调用更新UI的方法，这样，维护数据，展现数据，两个部分就获得了分离，维护性就是这样来的。

那么，咱们写一个界面程序，每次都闷头写吗？有没有什么套路呢？我就在想，是否是有一种共性，有一种通用的作法，一种高屋建瓴的理解，能够在一开始就让代码漂亮呢。通过我仔细思考和总结后，有了以下的体会。大概是这样：

其实界面程序主要分为两个部分：处理数据，处理UI

处理数据实际上是很宽泛的，包括处理内存的数据，处理本地的数据，处理网络的数据。你存成员变量，一个列表排序，其实都是处理内存中的数据，下载文件，存配置到文件，其实就是处理本地的数据，发送网络请求，处理回包，其实就是处理网络的数据，处理回包实际上是从网络到内存。

处理UI其实就是更新UI，或者动画什么的，动画什么的其实不要紧，随便搞吧，没啥。更新UI实际上是时刻关注着内存中的数据，内存中的数据就决定UI要展现成什么样。

接下来再思考一下，方法的层次/分类。这个就是说，方法应该分红哪些类别，哪些方法是有相同的特色。其实能够分为三类：

• 时机/用户操做

• 逻辑/处理数据

• 更新UI

时机/用户操做，是整个界面程序的驱动力，整个界面能运做起来，彻底是靠这些方法。好比

onCreate
onStart
onClick
onDestory
onCallback // 网络数据回调
onTimer    // timer,定时器

这一类方法，是第一层，最早被调用的方法。这些方法被调用后，里面就是咱们的逻辑部分，或者数据部分，好比用户输入了什么要存起来啊，点了个按钮发起网络请求啊。这一层方法，咱们能够本身命名，本身建，随便本身搞。好比：

requestData
handleData
doXXXXXX

最后一类，就是更新UI的方法，按我如今的理解，只须要一个就好了。

updateView

所以第一层方法，能够调用第二层方法，和第三层方法。第二层方法，能够调用第三层方法。按照这样的逻辑进行组织，逻辑就会清晰的多。

总结：

• 一类工做放到一个方法中处理，一个方法只处理一类工做

• 要注意整个界面中全部方法的层次，要有总体的把握，不要无谓的为了抽象，重用增长方法，应当减小方法，让总体逻辑和调用顺序清晰起来

• 在实际操做以前，先整理下，有哪些网络请求，数据要如何处理，UI关心哪些数据，而后再着手去作