雜

Template模式定義

：定義一個操做中算法的骨架，將一些步驟的執行延遲到其子類中。其實Java的抽象類原本就是Template模式，所以使用很廣泛，模板方法模式在Servlet中的應用 。

　　使用過Servlet的人都清楚，除了要在web.xml作相應的配置外，還需繼承一個叫HttpServlet的抽象類。HttpService類提供了一個service()方法，這個方法調用七個do方法中的一個或幾個，完成對客戶端調用的響應。這些do方法須要由HttpServlet的具體子類提供，所以這是典型的模板方法模式

 

parseInt用法

• parseInt(s);
• parseInt(s,radix)

　　第一個方式再也不多說，第二個方式，radix是s所基於的進制。範圍爲2-36（不在此範圍函數將返回NaN）。今天遇到下面的狀況：

 　  對於parseInt("01")到parseInt("07");都能獲得正確的結果（0-7），但若是是parseInt("08") 或parseInt("09")則返回0；這是爲什麼？

　   經研究發現parseInt當不指定radix時，當以0x開頭時，s按照十六進制計算的；若是以0開頭且第二位不爲x,則s是按照八進制計算的，由於八進制不能有8，9因此報錯返回0。

　　parseInt("08",10) 或parseInt("09",10),將分別返回8和9，

　　因此，在咱們用時仍是明確指定進位制，以防出錯。 （IE9 以上沒有此問題）

 

REST 表述性狀態轉移（REpresentational State Transfer）的簡稱

　Roy在他的論文中提出了一個RESTful應用應該具有的幾點約束。

• 每一個資源都應該有一個惟一的標識
• 使用標準的方法來更改資源的狀態
• Request和Response的自描述
• 資源多重表述
• 無狀態的服務

　　Roy認爲，只有具有了上面的約束的應用才能算是REST應用，其實如今好多所謂的REST應用或服務，其實並不能算是真正的REST應用。

　　我發現，其實目前不少所謂的REST應用，只是RPC而已，出現這樣的狀況其實很正常，由於RPC實際上更符合通常程序員的思惟。其實REST和RPC之間仍是有很大的差別的，下面咱們說一說REST和RPC之間的區別。

• REST強調資源有惟一的URI；而RPC更增強調過程（動詞），由統一的接口來調用它們。
• REST迴歸HTTP最初的設計；RPC僅僅只是把HTTP做爲傳輸協議來使用。
• REST是由超文本驅動的；RPC是由方法驅動的。
• REST強調HTTP通訊的語義可見性，經過消息頭和標準的HTTP方法來體現；RPC把語義封裝在HTTP消息體中。