以Android的環境特性來看，這種事情遲早要碰到...

「核心功能的元件要整個換掉。」

這種事情理論上不難處理，但發生時經常讓專案的工程品質競爭力崩潰。

萬一元件再多個地方被使用，那就要修改多個地方，——很多時候不單單是修改使用的元件而已，還要修改使用過程的邏輯，去調用原本無法取得的參數、環境、跟權限。當需要在很多地方做這麼多事情時，下一次發布更新的品質就令人堪慮。

什麼？貴專案的測試人力充分、計畫充實？恭喜！你們選擇用「硬力拆解」的方式對付這個問題。對那些沒有人力資源的團隊來說，很遺憾的，這種事情基本上無解、只能預防。

曾在「每個專案的程式碼都該這樣開始」講過「實作每個常用介面跟物件」，這就是預防的絕對手段。

假設：未來全面棄用OnClickListener，新元件也不提供「onClick(View view)」這樣的函數作為接口...

要怎麼用「實作每個常用介面跟物件」來預防這種事情發生呢？

回頭把上次的範例挖出來，並且加點料.......

abstract class ProjectClick implements OnClickListener{
   void onClick(View v){
     click(v);
   }
   abstract click(View v);
   
   void callbackView(View v){
     v.setOnClickListener(this);
   }
}

這個「callbackView(View v)」是為了方便解說而設的權宜之計，實務上有可能會造成很多限制而失去它本來追求的功效，所以除了實作以外再改用其他模式可能會更理想。

總之，假設新的元件就稱為「ClickCallback」吧！而它提供的接口是個「clickEvent(ClickEvent e)」，需要藉由「ClickEvent」去取得View，那就可以在不更動所有使用ProjectClick的情況下，讓整個專案的所有Click都適用新機制。

如下：

abstract class ProjectClick implements ClickCallback{
   void clickEvent(ClickEvent e){
     click(e.getView());
   }
   abstract click(View v);
   
   void callbackView(View v){
     v.setOnClickCallback(this);
   }
}

上面這是期望值。

而下面這是糟糕的現實。

使用新元件並不是件很簡單的事情，但事實上「推廣大家使用新元件」「跟大家解釋新元件基本用法」「為了辨明新舊元件優劣而開啟論戰」的人很多，但願意正視「這種升級有多困難」的人很少。

因為「教學」變成一門龐大的生意，而這門生意的主要客群是「尚未入行的新鮮人」，偶爾會有「不用把時間都花在加班熬夜改程式」的專案管理或技術經理。

結果？

1.現有專案慢慢成了技術孤兒，到了網路論壇上漸漸沒人討論它，光是發問都會惹來「為什麼還不用新元件？不要那麼排斥學習新技術啊！」的「攻擊」。
2.在舊框架還沒優化完畢的情況下，就忽然被要求要採用新技術（因為這疑似「能帶來很多好處」）。

但不管是哪個，專案都會死。