今天的筆記

我在高中讀的國文補充教材〈梅花嶺記〉，提到了史可法死前的故事，讓我印象深刻至今。 大意是史德威臨危受命，要取史可法性命不讓它落入敵人手中。怎料在危機關頭，德威終究心軟沒能砍下殺死史可法那一刀。最後還是讓史可法被綁到敵軍面前，大罵而死，連屍體都沒能保存葬於梅花嶺。一次違背兩個交代。 我看完後只想說：「德威，你真的蠻雷的。」。

 在最近開發的過程中，發現了每次增加新的 feature 就要來重構，想要歸納一下每次我在做的事情。 我想我每次重構的心得如下： inner static class 最後好像還是會被抽取出來 在一開始，必然是先用簡單的變數組合來代表某一觀念。 然後會組成 static class ，概念是不必要讓這個類別暴露給其他類別知曉。 然後在功能越加越多的時候， static class 一定會被獨立出來。而通常有兩個原因： static class 變得過大。如果一個 inner class 的內容與他的 outer class 內容差不多多的話，那還是不要放在一起喧賓奪主了。 static class 會被第三個類別存取。在這種情況下，當初的封裝變得多此一舉了。 那也許一開始就不要用 inner class ？ Strategy Pattern 終究會被引入 在一開始通常沒有這需求，等到差異性顯現出來時，不抽成抽象方法而是使用 interface 作為參數傳入。 這在美感上也比較討喜，將兩件權責劃分開來，測試的時候的排列組合更少。（個人想法） 終究會抽出更多短方法。 在一開始寫的過程中，總會覺得這段邏輯抽成方法太冗。 但在重構的時候，卻又反而會覺得他不易理解。 「不要輕易相信自己的記憶」？同一段程式碼在過一段時間回頭看仍需要重新理解它？ static / non-static 來回切換。 在最後總有些東西好像擺在 static 也行  non-static 也不錯，這時候會經歷來回切換的時期，不過或許在更之後，重新審視就會覺得這個東西應該是無懸念的  static 或 non-static。 方法的參數過多，通常會被拆開。 這個確實就是所謂的壞程式碼的味道，幾乎一定會需要被拆開。 盡可能地多命名。 這跟第三點很像，每次回來還是需要重新理解，所以第二次第三次回來看的時候，都會再給所有暫存變數更好的名字。 終究第一次取的名字就是不好，第二次的也差不多活不久。 在新暫存變數、新功能引入的時候，不免會有與現有命名重疊、或不一致的情況發生。所以第一次和第二次的命名大概以後都會被爆改。 終究會引入 stream。 有時候只是沒有把判斷式寫成方法，就直覺得寫 for loop ，但重新回頭看，用 stream 這樣有點 transcation 概念的解決，...

第一篇居然是菜雞的自以為的寫法，誠惶誠恐。我想試試看能不能在網路上找到共鳴，或當然，有指正那最好了。 在寫 java 的過程中，一些與類別實體無關的方法，就會很自然而然地把他們寫成 static method，然後包裝在一個只含有 static methods 的 class，在命名上給他加上個 -Utils 後綴。 這個寫法的啟發，來自於在公司參加的 Clean Code 讀書會。在 Clean Code 的第三章，作者 Uncle Bob 提到「應該避免使用多於兩個參數」。那當參數過的時候該如何解決呢？很簡單，把其中幾個參數提升為類別變數就可以了。 這讓我想到在專案裡面四散的 static methods，幾乎每個方法的參數都有五六個以上，其中又至少有三四個是要層層傳遞下去的。而仔細一看，層層傳遞的那些變數基本上都不會變化。 該怎麼做呢？ 我現在嘗試的寫法，是建立一次性的類別物件來處理。 以矩陣乘法為例， static method 的寫法如下： Matrix c = MatrixUtils.multiply(a, b)    一次性物件的寫法如下： Matrix c = (new MatrixMultiplier()).multiply(a, b) 以上的例子或許過於簡單，不過在構想裡是，把「設定」類型的參數放在建構元中，或者把所有的所需要處理的參數也都放進來（畢竟是一次性的），然後再處理的過程中，讓類別方法去修改類別變數，降低每個方法的參數量。 我想，對於與實體較無關聯的功能，寫成 static method 再正常不過。 但當完成一個 static method 需要呼叫多個 static method 的時候，或許就可以考慮用類別進行封裝。 或許是因為這個方法太顯然？或太不值一提？我不是很確定這個東西有沒有名字，我自己暫時把它叫做 Builder-like 寫法。如同 Builder Pattern 最後總是呼叫 build() 來結束這回合（回傳建立好的物件），這個寫法也是呼叫某個方法完成所有事情，就可以把這個物件拋棄。  但這個寫法缺點是有點不直覺，同時完全使用 static method 的寫法也沒有任何錯誤，這樣的寫法差異算是哲學層次的。究竟以後會不會繼續這樣寫，我也不是很清楚。只是先紀錄一下，想知道以後自己會...