之前在翻译学习EOPL过程中回顾以前的代码时发现一个让人后背发凉的危险，一种极其稀有、可是一旦出现就难以发现并或许形成非常大影响的bug，本文就记录下这个问题。

问题场景

下面来看一段常见的示例程序：

public class DemoActivity extends Activity {
    public static final String TAG = DemoActivity.class.getSimpleName();
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        findViewById(R.id.btn_test).setOnClickListener(new BaseClickListener() {
            @Override
            protected void onClicked(View v) {
                Log.i(TAG, "onClicked: clicked");
            }
        });
    }
}

这是一个避免快速点击的示例，这个程序中类DemoActivity包含了一个BaseClickListener的匿名内部类，然后这个类中引用了外部类的声明的变量TAG（好像是这样）。但事实上，BaseClickListener的完成是这样的：

public abstract class BaseClickListener implements View.OnClickListener {
    public static final String TAG = BaseClickListener.class.getSimpleName();
    private long lastClickTime = 0L;
    @Override
    public final void onClick(View v) {
        long currentTime = System.currentTimeMillis();
        if (currentTime - lastClickTime >= 500) {
            onClicked(v);
        } else {
            Log.d(TAG, "onClick: click to fast");
        }
        lastClickTime = currentTime;
    }
    protected abstract void onClicked(View v);
}

因此在DemoActivity中匿名内部类引用的其实是BaseClickListener类中声明的TAG。这儿发生了变量隐瞒的现象，并且仍是一种不行见的、“隐式”的隐瞒。这种隐瞒的存在使得外部文件的修改能够直接影响其时文件的语义。

试想，这两个类归于不同的模块，甚至不同的项目，运用BaseClickListener的人甚至有或许不会去看源码、甚至拿不到源码，而编写BaseClickListener的人更不会考虑DemoActivity的完成。一开始BaseClickListener类中或许没有TAG变量，DemoActivity中对TAG的引用指向DemoActivity.TAG，后来BaseClickListener引入了这个变量，这时候，不管是DemoActivity的开发者仍是BaseClickListener的开发者都不知道这儿出了问题，而DemoActivity的程序语义已经发生了改变。

上述示例程序中问题规划仅仅是打印日志，所以影响规划有限。但假设换成其他的变量，比如常见的id、rootView、name、content、currentTime、count等等等等，那么命运好的情况下直接编译不过，命运欠好的情况程序崩溃甚至数据污染，并且这个问题需要通过盯梢变量引用才能发现，光肉眼看还或许看不出来。

我还没有在实际项目中遇到过这个问题，但假设真的遇到了，那我或许要跟我的同事“友尽”了，因此将其列为“友尽”级bug。

问题剖析

上面问题发生原因如下：

  1. 这是“隐式”发生的隐瞒，仍是无意识的隐瞒，且隐瞒跨越多文件；
  2. 变量/常量/办法声明界说与运用跨多文件，且引用选用简化办法，并非彻底办法；

首要简明谈谈隐瞒（shadow）。（之所以简明，是由于这个概念结合作用域、上下文来讲比较简单讲透，这个另外在写文章总结）

隐瞒在现在大部分流行言语里都或多或少出现一点，除了上面展示的，还有例如下面javascript程序中典型的隐瞒：

function outer(x){
    function inner(x){
        {
            let x = 3
            console.log("x1:" + x)// x = 3
        }
        console.log("x2:" + x)// x = 2
    }
    console.log("x3:" + x)// x = 1
    inner(x + 1)
}
outer(1)

这种隐瞒还相对安全，由于是可见规划内发生的显式隐瞒。可是Java的类作用域与词法作用域结合使得能够发生隐式的隐瞒，只需出现内部类，不管是成员域仍是办法甚至局部变量都有或许发生这类隐瞒。这是言语规划中的意外，关于言语运用者来说难以避免这类问题。

一点点主张

  • 最差的主张：避免运用内部类；
  • 次好的主张：关于类的成员域以及办法的访问选用全限定名，比如：OuterClass.this.name
  • 较好的主张：外部类可运用简写来引用成员域或办法，内部类则选用全名。