T17 元件工具(3)──把Component整合回一個Class

在設計元件的時候根據不同的特性將程式碼佈置在不同的部分裡，使得一個元件對應為多個部分。在之前大陸的專案裡測試發現，執行起來的效率並不會特別緩慢，所以系統就直接執行而未對元件內部多作任何處理。不過在講求效率的系統之下，多個Class勢必會影響其效能，因此還是必須有應對的策略。

對策是將性質相近的部分整合回一個Class裡，也就是把Implementation、Flow、Action與Properties四者的Interface、Abstract Class合併在一起（Component Interface、Model與Exception本來就應該獨立存在）；整合之後的結果已經與目前常見的寫法沒有差別。整合的邏輯大致如下：

建立名為ComponentAbstrct的Abstract Class實作ComponentInterface。
●Implementation、Flow、Action與Properties四者的變數、建構方法、initialObject()與disposeObject()內容合併在一起。
●Properties內屬於此層級的所有常數與方法搬到ComponentAbstrct並在名稱前加prop_（常數名稱不變）。
●Action內屬於此層級的所有常數與方法搬到ComponentAbstrct並在名稱前加action_（常數用大寫）。
●Flow內屬於此層級的所有常數與方法搬到ComponentAbstrct並在名稱前加flow_（常數用大寫）。
●Implemenet內屬於此層級的所有方法搬到ComponentAbstrct，毌需重新命名用以實作ComponentInterface的宣告。
●檢視所有ComponentAbstract方法裡的程式碼，使用getComponentXXXX().CONSTANT方式呼叫的方法，全部改為xxxx_CONSTANT來呼叫（Properties的除外）。
●檢視所有ComponentAbstract方法裡的程式碼，使用getComponentXXXX().method()方式呼叫的方法，全部改為xxxx_method()來呼叫。

在理論上這樣的整併是可以達成的，因為變化只在元件本身的內部；不過要把這個功能寫好卻是很不容易的事，因為有許多環結的細節都得緊密銜接才不會造成問題。目前先把這個功能的實現放在一旁，等必須要作的時候再回頭完成它，因為即使沒有整合回來元件還是可以正常執行的。

這樣的整合之後，負責元件內部合作的基本Component已經沒有存在的必要，因為元件內的互動都在ComponentAbstract裡。但是放置所有元件基本功能方法的RootComponent還是要有，因為功能方法並沒有任何取代的地方；這正是需要把基本Component與RootComponent分開定義的原因。

註：方法、常數與變數更名時的對應若特別記錄起來，用特別的運算方法來轉換名稱，就能夠達到混淆的功能；抑或是把某些方法的程式碼嵌到呼叫它的地方造成方法的消失。這兩種作法都能有效降低程式碼被反組譯後的可讀性。