[Java/Android]選取Spinner的內容同時改變Button的功能 (我會怎麼用純物件的方式寫這個功能)

(接續上一篇)還是這個功能/介面，資料處理方式可能是「各種加密方法」或「將資料傳向特定網站或資料庫」。

用「進化」的觀點來看，結構化程式設計技巧確實比物件化程式設計技巧更基礎。(前者在60~70年代出現並成熟、被發揚光大，後者雖然同時期出現，但Java卻是90年代的東西了。)

不用物件導向技巧還是可以在物件導向語言裡寫出可以運作良好的程式，只是...「維護」和「擴充」(特別是要由第三者來維護跟擴充)就很讓人「蛋疼」了。(女工程式請不要介意...)

我會先設計一個這樣的介面Interface(不是UI介面)。

看名稱應該就知道，這是擴充後要給Spinner/下拉彈出式選單作為內容的介面。

我擴充這個介面產生一個新類別，並在getText()中設定「return "功能一"」，如果用這個類別宣告實作物件，並將物件塞給Spinner的SpinnerAdapter，則選單中就會有「功能一」這個選項。以此類推...要多少有多少。(中間有一些設定SpinnerAdapter的細節，如果不知道自己推敲應變，那我這段描述會變得很怪。或者你知道使用其他Adapter來取代......)

然後再設計一個OnItemSelectedListener，──給Spinner使用的。這個OnItemSelectedListener具有「偵測」使用者選取了哪個Spinner選單內容的能力。(看到第22行的程式碼，那是個函數，裡頭有個「int position」，這就是「使用者選擇的參數」，──或者說是「選單中的第幾個選項」。)

Button b1就是「送出」鈕。藉著將這個Listener設定給Spinner，程式會即時、動態(使用者每選擇一次選單內容)的變換這個按鈕的OnClickListener。(list就是用來「裝」選單內容的地方/物件。)

(上面這個程式範例有嚴重的錯誤就是「它是OnItemClickListener」。但Spinner雖然保有這個屬性，但卻無法使用，執行Spinner的setOnItemClickListener......還沒成功過。幸運的是，除了名稱不一樣以外，它和OnItemSelectedListener結構與傳入參數都一模一樣。)



如下圖，這是Activity，可以看到我一共產生了三個選項，分別是「Test1」、「Test2」、「Test3」。(恕我省略HsuSpinnerAdapter的內容。因為就是個繼承自SpinnerAdapter的類別)

這支程式只會很可笑的把「Test1」、「Test2」、「Test3」作成小框框內的文字顯示在畫面上而已。但確實是「三個不同的功能」。



如果想要，可以自己設計獨特的SpinnerItem，然後放進list中，未來要擴充功能就會變得很簡單。

「難道不用物件導向技巧會變得很難寫嗎？」

這樣假設吧......今天有個「Test1.5」要放進「Test1」和「Test2」之間，那可能只要在ArrayList<String>的 「Test1」和「Test2」之間放進「Test1.5」，就會出現這個選項。

問題是「送出」按鈕的OnCLickLitener中，要將所有判斷式的position值重新修改，......其實也不難，但是如果又出現了「Test1.4」、「Test1.3」、「Test2.1」.......無限增加中，只要這個程式還活著、專案管理和企劃人員腦筋動個不停，這種事情就會發生。

當OnClickListener的程式碼長達八九百行、甚至一千五百行時，不停重複修改一支Class就不是讓人很愉快的事情了。

所以為何不在程式剛開始、專案剛起頭時，想好一個將來方便擴充的機制呢？

(文章寫到這裡，我又想到一個修改SpinnerItem的方法，將來就算要直接新增一個選單，──也就是一共會有兩個選單──也可以輕鬆擴充、修改的設計，......物件導向就是這麼迷人。)



上面的那個問題好像有點廢話，但問題是「有些工程師會認為像我這樣寫程式才是廢話。」

因為「物件架構」不是一翻兩瞪眼的東西，如果架構不可行，理論上有時後看不出來，要有具體程式碼才能驗證，而且驗證一次不夠，可能要兩三次。

第一次驗證失敗後，已經有一個功能和三千行程式碼，第二個功能進行設計完成時，要進行第二次驗證，結果又失敗，這時已經有六千行程式碼，結果這六千行幾乎都要打掉重寫，重第一個功能開始驗證......重複這樣的過程，直到確定架構可以重複運作在...「所有功能上」。

可能五六個星期已經過去了。

但是......直接抓起規格書，開始用土法煉鋼的「一個功能就一個物件/Activity」這樣寫，可能兩個禮拜就把初步規格書上所有的功能都完成了。

當這些工程師可以不斷一次又一次超前進度、快速精準完成專案時，「物件導向」就變成了「Java語言不方便的特性」而已。去精熟物件架構、去專研怎樣設計物件架構、累積設計物件架構的經驗.......只是一場笑話罷了。




這就是JAVA設計師的絕境與哀愁啊！物件導向其實好學！只要認真寫教學文、教學範例。甚至可以用Library重新包裝所有JAVA基礎程式指令，例如更精簡、更快速的Socket建立方式。寫JAVA？哪那麼難？

但是一堆人把JAVA當成單純的結構式語言、當成C/C++工程師找工作時的代替品，認為「要精通很多指令」(或說是「同一個指令要有很多次使用的經驗」)、「要能閱讀並掌握大量程式碼」、「要能快速、用直線思考的方式實現規格書的需求」......才是工程師之道。