HTTP v.s. SOAP

HTTP 可以提供各種服務 - HTML, images, sound, video, etc.
SOAP 是在 HTTP 上面, 專門提供 XML 傳送的服務.

SOAP 的request 如下，HTTP headers在上面, SOAP message 在下面:

---------  HTTP portion of the message ------
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

---------  SOAP portion of the message ------
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStockPrice>
    <m:StockName>IBM</m:StockName>
  </m:GetStockPrice>
</soap:Body>

</soap:Envelope>

reference:
Difference between SOAP and HTTP protocol <Link>

HTTP Request methods - Get and Post methods

HTTP Request methods 有下列8種方法:

1. GET
2. POST
3. OPTIONS
4. HEAD
5. PUT
6. DELETE
7. TRACE
8. CONNECT

先介紹最常用的 GET 與 POST 方法:

1. GET：取得我們想要的資料。把查詢資訊放在URI上, 「取得」想要的資訊。 
• Ex: http://xxx.toright.com/?id=010101
2. POST：新增一項資料(不會覆蓋舊資料)。要求Server接受的資訊是附在請求本體（Body）, 而不是在URI上

Reference:

1. 常見的HTTP METHOD的不同性質分析 <Link>
2. 重新認識HTTP請求方法 <Link>
3. 淺談 HTTP Method：表單中的 GET 與 POST 有什麼差別 <Link>

OOD 原則 - SOLID

OOD 原則 - SOLID

物件導向設計 5 大原則:
1. (SRP) 單一職責:
    一個類別只負責一件事情

2. (OCP) 開放/封閉原則:
    開放擴充, 關閉修改

3. (LSP) Liskov替換:
    子類別應該可以替換掉父類別而不會影響程式架構

    子類別可以擴充父類別的功能, 但不能改變父類別原有的功能。子類別不要覆蓋父類別的方法!
    -->設計上應該少用繼承, 多用composite/aggregation 達到re-use目的 (i.e., 做一個wrapper 包住 base class)
    --> CARD - 先思考 Composition/Aggregation 的 Reuse ，真的沒辦法才思考 Derivation

4. (ISP) 介面隔離:
     使用多個專門介面, 比使用單一總介面要好! 把不同的函數從介面中分離出來
    --> 不同的函數應該屬於不同的介面

5. (DIP) 依賴反轉
    高階模組不應依賴低階模組，兩個都應該依賴在抽象概念上

    抽象不應該依賴於細節, 細節應該依賴於抽象!
    --> 針對介面寫程式
    --> Dependency Injection 是實作 DIP 的手法 (例如: 通過Constructor注入依賴)
    --> 若一個Constructor注入太多的依賴，則此Class 可能違反了SRP

SRP 與 OCP 都只是一個方向, 不是教義! 寫程式要專注一個主要的核心任務, class要盡可能簡單, 但是不是教義!

Callback 的意義

引用http://www.programmer-club.com.tw/showSameTitleN/c/20869.html

callback，字面上的解釋就是「回呼」，這牽涉到多工作業系統中兩個同時執行﹝concurrent﹞的不同模組。

一種情形是，A 模組給 B 模組一個 function pointer，請 B 在處理完某項工作後，或是在適當時機，使用這個 function pointer 來呼叫該 function 函式。

例如，A 模組裡面寫了一個 function 叫做 CallMeIfDone，然後它啟動了 B 模組，並且把 CallMeIfDone 的 pointer 傳給 B 模組。A 模組繼續執行它的工作，B 模組也同時在處理它的事情，等到 B 模組忙完了，它就會呼叫 CallMeIfDone，但是這個函式是寫在 A 模組裡面的，所以實際上是跑回來 A 模組的地盤執行 CallMeIfDone，因此就稱為「回呼，callback」。

另一種情形是，B 模組是一個獨立執行的模組，專門處理使用者輸入，每當使用者敲一下鍵盤，或是動一下滑鼠，它就會產生一個事件，需要處理這些事件的其他模組必須向 B 模組登記 callback，例如 A 模組向 B 模組登記了 KeyboardEvents 的 callback，那麼 B 模組在偵測到鍵盤動作時，就會去呼叫這個callback了，當然這個callback也是寫在 A 模組裡面的。

MVC 架構 - 以 Hyena 為例

MVC 架構以 M 最為重要! 說明如下:

• Model: 存放資料，當資料改變時，透過 C 來更新V
• View: 只是視覺化Model
• Controller: 當 M 改變時，用來更新V

為了達到 "當 M 改變，透過 C 來更新V" 的目的，Controller 要能夠看得到Model 與View:

其中，Controller 的 RegisterView() 如下:

如此便可以把 M 的改變 呈現在 V  上面。

MVC的優缺點如下:
** 優點:

• 可以用不同的View 呈現相同的Model
• 容易對 Controller 進行測試 (Testability => mockup Model for testing)，適合TDD

**缺點:

• 採用Event-driven，是一種複雜的UI design pattern
• 需要透過Controller 來更新View，很耗資源 

另外，請參考Hyena的Class diagram，Model 也用來執行真正的Business:

MVC 不是一種技術, 而是一種設計理念!

什麼是多型 (polymorphism)

所謂的"多型"，指的是 runtime 時期執行的內容。
在C#當中，有下列四種多型的意義，其中最常提及的就是OO的繼承式多型:
1). 繼承式多型 (inclusion)
在design time，可以用父類別型態容納子類別的物件，在 run time 進行函數呼叫時會呼叫到子類別的函數，重寫 (override) 父類方法

2). 泛型
List<T> 中的 T 就是參數型別，依據參數的型別決定實作的內容

3). 運算子多載 (overloading)
C#可以多載運算子 (ex: 可以重寫 == 的行為)

4). 強制同型 (coercions)
自動將型別轉換，ex: 在 run time 時 int 轉成double



"多型"與"動態繫結(Dynamic Binding)"是相關的, dynamic binding可利用(virtual function)來達。

1). 晚期繫結也稱之動態繫結(dynamic binding)。
簡單的說，就是物件的行為並不是在編譯時期 (compileir-time，就已經決定了。而是在程式執行時期於(晚期)(run-time)才動態地決定 的。如何動態地決定。就看物件當時的狀態(state)而定，物件封裝了所有可能的狀態處理 方法，並且根據外邊送來的訊息做出適當的反應。這也就是晚期連結的意義，這是物件導向 一個很重要的精神。

2).繫結
是將程式中所使用到的各名稱(包括程式名稱及變數名稱)，分配到適當的記憶體位置。
其中在編譯過程中即完成連結的稱為靜態繫結（Static Binding），又稱為早期繫結（Early Binding）。如果是在程式執行過程中才完成繫結的，則稱為動態繫結（Dynamic Binding），又稱為延後繫結（Late Binding）。

專業主義

大概在今年6月底收到MTD team的需求，希望開發一個Tool，把所有machine test reports 做一個資料分析，彙整成一份報告(csv格式)。

以下是一開始從MTD team收到的資訊:

• 目前大約有200台machines, 都放置在 ~\machine_data 資料夾裡面
• 每個machine有60個test report要分析
• 每個test report 依據test name，存放在~\mXXXX\test_results\YS@prepship\Test
• 每個test report的xml格式都很類似

時程估算方面，依據之前工程師用matlab開發MAS的經驗，一個test report大約一個小時，所以粗估60個test reports大約要7天。

然後，我就開始做了...災難也開始了...

首先，根據MTD team的說法，由於我先前已經做了一個parsing tool，所以"只要修改一下"原本的parsing tool，便可以符合他們的需求。
這個認知整慘我了...
因為 input 與 output已經不同了，我幾乎是重寫整個parsing tool，這部分大概花4天，絕對不是"只要修改一下"

再來，MTD team給我的資訊只有部分正確，詳述如下:

1. 目前大約有200台machines, 都放置在 ~\machine_data 資料夾裡面
• 錯! 200台machines的資料放置在 ~\machine_data 與\\172.xxx.xxx.xxx\d 資料夾裡面
•  ~\machine_data 不需要 Id/Password ，但是\\172.xxx.xxx.xxx\d 需要Id/Password才可連線，這部分大概花了1天
2. 每個machine有60個test report要分析
• 錯! 60個test report是200/250的machine，後來又新增加了12個350的test reports
• 這12個新增加的test reports是全新格式，這部分大概花2天
3. 每個test report 依據test name，存放在~\mXXXX\test_results\YS@prepship\Test
• 錯!~\mXXXX\test_results\YS@prepship\Test 這個資料夾結構是人工後續手動輸入，因此有很多錯誤，造成test report 找不到
• 因此，只好加入log，針對找不到的test report手動把資料夾結構調整成正確
• 手動把資料夾結構調整再加上log機制，就花了3天
4. 每個test report的xml格式都很類似
• 錯!xml schema只要有一點點不同就必須"特別處理" (special handle)。幾乎每個test report都要個別處理，共通性的test report少之又少...
• "特別處理"意味著需要額外的effort，大概花了6天

另外，最後彙整產出的csv檔案還需要加上:

• 顯示machine type (從CM_Options.xml讀取)
• 顯示單位(從HTML而來)
• test report (xml) 與CS 習慣閱讀的HTML，KPI顯示的字串不同，必須一個一個檢查

這些零零總總又多花了3天...

總結上述天數是19天，是原本粗估(7天)的2.7倍...
在開始專案之前，我應該要審慎評估的，這才是專業!