由於 WatchDir 中，為了使用 textArea 來顯示訊息，所以把 textArea 當作參數傳給 WatchDir。此外，textArea 使用String.format處理產生的訊息。
這樣的寫法，其實變成日後要加新的「訊息處理者」，如 MessageDialog 來產生 alert 對話視窗時，變成要再加參數傳給 WatchDir。而且使用的 ? 方法，也要另外再寫 String.format 來處理對應的訊息。因此這部分需要作修改，重構一下。
讓 WatchDir extends Observable，把所觀測到的檔案訊息，包成一個 final 物件FileMonitorEvent，將訊息資料傳入個別的 Observer 作處理。作成 final 物件，是因為檔案異動訊息一產生，就不能被更改。圖中的 Observer (藍色部分)，不一定需要實際的 class ，也可以用 lambda 或 anonymous 的方式。
此外，一個監控目錄，應該對到一個 OptionDialog，也就是之前提到的 UseCase 中，除了顯示檔案異動訊息之外，其它的動作設定，均會在這個 OptionDialog 中。而個別的 Observer 也會在這個 OptionDialog 實作。如此將來可以擴充成多個 OptionDialog ，就可以監控多個目錄。
再回頭看一下這兩個 Class Diagram，也許會有人認為，其實一開始是可以設計第二張圖的，為什麼不一開始就「設計好」呢？這個部分要思考一下幾個想法。
首先，每個人寫程式的方式其實是不一樣的，即使是同一人，每次作法也不見得會一樣。以這個監控檔案異動的程式，當初在寫的時候，「重點」是趕快寫出來，讓監控檔案異動的部分可以動再說，如果實際上 Java API 作不到，可能要採用其它的語言來寫。
第二，因為不了解實際 Java API 處理檔案監控的機制為何，所以一開始也無法很快了解要用到 Observer pattern 來處理「檔案異動訊息」，而原本的範例程式，就 for 一直跑，要修改成 Thread 來使用。再加上之前寫的都是 Server Side 的 Java, Swing 很久沒寫了，WindowBuilder 也才剛用個「幾天」，雖然很直覺，很好用，但總是要花時間摸索。如果不先把功能作出來，大概時間都會花在處理了解這些 Swing 元件 或 找 pattern 了。
第三，這其實是個小程式，因此初期不需要太多的設計，就可以很快實作出來，而會卡關的，除了對 API 不熟之外，還有環境的不了解，因此，當初寫的時候，「一不小心」就花了半天的時間去查「所有可以監控檔案」的程式寫作，包含 windows 的 API 等，最後才發現，就用 Java 自己的 API 就可以了。這樣寫程式，很容易「發散」沒有專注。
上述的想法，在寫作小程式或試驗的時候，是可以這樣處理的。大型專案就比較難這樣作。因為大型專案如果沒有作好設計，一開發下去，若有問題，人力物力還要重新投資。
從想到作，寫大概的 UseCase，程式實作出來，作 Class Diagram，然後再改成新版用 Observer pattern 也花了二天左右。真的作不對，整個打掉再來，也還能接受。
倒是寫這個 blog 文章花的時間比較多。因此，有一個構想點子，會比去了解更多有的沒有的技術，會更重要。因為這樣比較好聚焦在要處理的程式碼上。而技術的使用，在需求及功能初步達成後，再回頭重構也是可以的。
沒有留言:
張貼留言