2017年8月23日 星期三

【J2EE TomCat】執行專案顯示404

注意!

下面寫的是指專案環境剛剛建好、還沒有實質上寫過任何一行程式碼的情況下就碰到404。

如果有額外使用什麼框架,例如Spring或Struct,這些步驟非常有可能一點意義也沒有。



這個問題可以統整成幾個步驟...

1.TomCat沒有正常啟動。

先在「Servers」(視窗)內找到正在使用的TomCat Server項目,然後在項目上點選右鍵選擇「Properties」。會看到下面這樣的視窗...注意「Location」後面的路徑,如果沒有指向Servers,就按一下「Switch Location」、接著「Apply」並「OK」離開這個視窗。




再回到「Servers」,點選Server項目後打開下面的視窗。
注意看到「ServerLocations」,如果沒有在第二項「Use Tomcat installation」,那應該就是問題所在了。


有時候「ServerLocation」會整個鎖起來,這是因為沒有把「Servers」中的Server項目徹底暫停。(必要的時候可能還必須刪除。然後重跑一次Define流程。)


2.設定完卻忘了把舊的設定刪除。

注意!如果步驟1不管用,可能要到這裡來把項目刪除。(不然重建就一點意義也沒有了。)
 



3.忘了指定正確的JSP「Runtimes」環境。(也不一定是專指JSP,反正某個需要設定Runtimes的地方設定錯誤。)


這步驟相較之下簡單,就是「Runtimes」中的Server選項沒打勾,所以有檔案無法正確編譯、也就無法執行。(「Runtimes」在畫面最右邊。)


2016年12月27日 星期二

[Design Pattern]Strategy和泛型

【以下先是碎碎念...可以跳過不看。】

程式碼在概念上經常就只是「演算法」與「資料結構」的具體實現。

但在程式的整體「框架」上,很難從程式碼看出來整個程式的邏輯或概念。

除非大家都使用「演算法」來描述事情...但這不可能,實際上大家還是習慣用具體需求來描述事情,例如「怎麼找出特定檔案」。

但這件需求其實是種「快速比對檔案內容」的演算法,習慣上應該沒有人會用後者來描繪、形容、跟別人溝通,即使是工程師對工程師。(天知道有多少種演算法可以做到「找出特定檔案」這件事。)

所以Design Pattern被發明了!...(可以這樣理解吧?)

可是我發現很多人把DesignPattern當成一種程式碼設計的延伸,大家還是習慣用「具體需求」來理解「何時該使用哪種Pattern」。

【碎碎念完。】



Strategy這個Pattern對我來說是個優化、或簡化程式碼的好工具。

很多習慣函數式開發的工程師經常把程式搞成一大包,一支[.java]檔動輒上萬行是小事。這種程式碼難維護不說,擴充難度更是高。

碰到這種程式碼,一般來說我都會快速的將所有的函數一刀切成兩種:「有傳入參數」和「無傳入參數」兩種。(補充說明:還要先排除這些函數之間是同名異構的「覆載」函數。)

那些「無傳入參數」的函數基本上都是直接修改全域變數...所以就把所有非static型態的全域變數複製一份獨立成一個物件,先稱為「StrategyObj1」好了!(記得在原始程式中宣告一個StrategyObj1的實做物件。)

接著就可以將所有的「無傳入參數」的函數通通獨立出來實做成一個「內部不帶參數、只有函數」的物件/類別。


為什麼「無傳入參數」的函數會用「有傳入參數」的方式實做?

首先是為了方便未來擴充。

假設某功能需要使用者輸入資料一、資料二,例如居住地的縣市和詳細路段,但未來忽然需要擴充為兩組以上的地址,則只需要把資料一和資料二包裝成一個類別,然後宣告兩個物件並分別傳入對應的UI輸入結果,就可以繼續使用同一個Strategy物件函數來處理了。

其次...這可以延續物件導向的風格!

(未完)