今天身體不太舒服，還是輕鬆一點，來討論一下convention。Convention的意思是約定，初次看到這個名詞是閱讀一些關於Ruby on Rails的書，講到Ruby on Rails的設計哲學，很重要的一部分是基於Convention。

PHP的include與require是一種很有彈性的設計，配合一些設計上的Convention，即使只使用函數，也能做出有相當彈性的系統。
Ruby on Rails剛出現時，就因為他快速開發的特性受到矚目。他可以做出這樣的特性，有一大部分是因為許多系統的設計上，會需要使用者配合他制定的Convention。這包含：table, primary key, forgeign key的命名，model/view/control之間的mapping等。遵守這些Convention，很多事情Ruby on Rails就可以自動完成，例如直接從DB生成程式。

在設計系統時，有時會需要針對某個功能提供多種的實作，例如付款方式可以選擇轉帳、信用卡、點數等等，但是這些不同方法又都是一個固定的流程中的一部分。要設計這一類的機制，如果是使用OOP，大概會使用Strategy Pattern，也就是先將付款機制的流程規劃好，然後設計一個interface，用幾個不同方法來處理流程的不同部分，然後各個實作付款方式的類別，繼承這個interface，來處理付款的各個流程。服務的使用者在選擇付款方式之後，系統就會使用實作付款方式的類別，來實際處理付款流程的各個步驟。在這樣的設計中，其實interface也就代表了設計出來的Convention，需要各個實作共同遵守。

如果只使用函數呢？其實還是可以用類似的方式達成，只是把類別的方法改成使用函數，然後放在不同的程式檔，等使用者選擇了不同的付款方式，再把對應的檔案載入，然後根據流程呼叫不同的函數。這樣，也可以達到一樣的效果。

通常與金流介接，流程就分成兩個部分，一個是用post把資料送到金流系統，一個是接收金流系統用post送回來的資料。另外，在系統中也可能會需要編輯一些金流的資料，這樣就可以在程式檔中設計四個函數：

1. before()：在post之前彙整資料，然後送出request到金流系統。
2. after()：在金流輸入資料完成後，或是付款失敗，將結果post回來時接收並處理資料
3. edit()：顯示編輯金流資料的介面，例如商店代碼，金鑰，post回來的網址等
4. save()：儲存編輯的金流資料

在使用者選擇了付款方式之後，系統就用include/require載入相關的程式檔，然後呼叫before()，在下一個流程呼叫after()，然後再繼續之後的流程。這樣，利用流程上的Convention，就可以做出簡單的金流plugin。

先去休息，明天再介紹一下coding standard，這其實也是一種convention。