解耦解的早,改需求沒煩惱

梁山boy發表於2017-01-16

摘要

世上本沒有解耦,需求改的多了也便有了解耦。 —— 產品經理

本例將通過一個計時控制元件,聊聊如何解耦~

TimerView僅作為demo,不保證其健壯性,請勿在實際專案中使用。

特點

  • UI容器計時邏輯分離
  • UI容器具體UI佈局分離

原始碼

github.com/fashare2015…

Let's Go

話說,小明在做一個電商專案,有個倒數計時需求。

需求1.0

要求"時、分、秒"數字顯示。

這個簡單,小明很快自定義了一個TimerView:

public class TimerView {
    TextView tvHour, tvMinute, tvSecond;
    TextView divider1, divider2;
    ...
}複製程式碼

解耦解的早,改需求沒煩惱
需求1.0

需求2.0

介面太醜啦,加點顏色和背景吧~

這個也簡單,小明很快加了一些自定義屬性:

public class TimerView {
    TextView tvHour, tvMinute, tvSecond;
    TextView divider1, divider2;

    // 新增 自定義屬性
    int tvHourBgRes, tvMinuteBgRes, tvSecondBgRes;
    int tvHourColor, tvMinuteColor, tvSecondColor;
    ...
}複製程式碼

解耦解的早,改需求沒煩惱
需求2.0

需求3.0

這時,產品經理又跑了過來,你看我發現了啥~

發現一套火焰數字.jpg,好炫酷的說,幫忙改上去吧~

解耦解的早,改需求沒煩惱
需求3.0

小明內心:你TM有病啊!!!

你發現了麼,這下小明把自己帶到溝裡了。新需求要求顯示火焰數字圖片(ImageView)。
然而,由於TimerViewTextView構成,再怎麼自定義屬性也實現不了新需求(ImageView)了。
說的就是你呀:github.com/iwgang/Coun…

分析

為啥會這樣呢?因為一開始就設計緊耦合了。
TimerView依賴了具體子類TextView,功能也就被侷限在TextView了。
那我們只需這麼調整一下,把TextView改成更抽象的View
這樣一來tvHour既可以是TextView,也可以是ImageView,或者某個ViewGroup,功能得以擴充:

public class TimerView {
    //TextView tvHour, tvMinute, tvSecond;
    View tvHour, tvMinute, tvSecond;
    //TextView divider1, divider2;
    View divider1, divider2;

    // 自定義屬性也不用了,因為無法確定 tvHour 這些究竟是啥子類。
    //int tvHourBgRes, tvMinuteBgRes, tvSecondBgRes;
    //int tvHourColor, tvMinuteColor, tvSecondColor;
    ...
}複製程式碼

這也體現了軟體設計的一大原則:要依賴抽象(View)而不要依賴具體(TextView)。

依賴注入

還有一個問題:tvHour究竟是啥呢,這個得由使用者決定。
通常我們會提供一系列setXXX()方法給使用者進行設定。這個套路叫做依賴注入
依賴注入是解耦的一種常見的方式。通常,當你有無法確定的一些東西,都應該拋給使用者決定。
舉個例子,View被點選時,設計者不知道你想幹嘛,於是設計了View.setOnClickListener()。這是典型的依賴注入。

好了,ImageView可以支援了,然而對於介面更新ImageViewTextView肯定是不一樣的。
該怎麼更新又無法確定了,我們可以再次用依賴注入的方式解耦,把難題拋給使用者。
因此,我設計了類似Adapter的東西,都在程式碼裡,就不詳細展開了。

需求4.0

嗨呀~還不夠啊,產品經理的腦洞總是很大的。

產品經理:我看到一個 svg 誒~

小明:算我倒黴。不過,我早就重構解耦過了。改需求, 小case~

解耦解的早,改需求沒煩惱
需求4.0

需求5.0

產品經理:小明,你還活著那?我發現機械錶更好看誒~

小明: **, 我改就是了

解耦解的早,改需求沒煩惱
需求5.0

感謝

github.com/lypeer/Goog…

github.com/gnehsuy/Clo…

相關文章