物件導向編程Sample(C#)

Object Oriented Programming，OOP

本篇旨在講述如何以物件導向的思維編程

以下訂單為例，客戶通過web，填寫連絡人資訊、所購買服務（就是幾個checkbox，買幾個服務，就勾選幾個checkbox，價格基於所選擇的服務來計算）、網上支付；點了“提交”按鈕後，會進行如下操作：儲存到資料庫、信用卡支付、產生訂單pdf、發送郵件通知客戶。

 

一般代碼類似如下：

public class OrderController     {         OrderDAL dal = new OrderDAL();           public Guid PlaceOrder(OrderInfo orderInfo)         { //驗證函式，略               Guid orderId=Guid.Empty;             bool saveOk = false;             using(TransactionScope ts=new TransactionScope())             {                 orderId = dal.InsertOrder(orderInfo);                 if (!orderId.Equals(Guid.Empty))                     if (PaymentService.Pay(orderInfo.Price))                         saveOk = true;                   if(saveOk)                     ts.Complete();             }               if (saveOk)             {                 GenerateNewOrderPdf(orderInfo);                 SendEmail2Client(orderInfo);             }               return orderId;         }           private void SendEmail2Client(OrderInfo orderInfo)         {             throw new NotImplementedException();         }           private void GenerateNewOrderPdf(OrderInfo orderInfo)         {             throw new NotImplementedException();         }     }

上面這段代碼就是Martin folwer所說的”事務指令碼模式”，即：一個業務方法寫在一個函數裡，一大塊從頭到尾寫完。

 

如果想以物件導向方式來寫，該如何寫呢？答案是（我目前個人認為…哈哈）：畫出順序圖表，再進行編碼。

因為使用順序圖表能夠協助找到各個對象、以及各對象間的通訊方法，如下：

這個圖貌似比較複雜，因此只有當系統比較複雜時（商務邏輯）才會選擇用物件導向的方式來拆分各個對象，好處有：

1.       各個對象其實就是關注點分離，因此維護方便

a.       比如驗證那裡，修改起來非常有針對性，很容易定位要修改哪個類

b.      計算價格那裡也是，很容易定位到需要修改的地方

2.       單元測試時，可以單獨測試各個類，而不用給PlaceOrder寫無數的測試函數（分而治之）

a.       如果是“事務指令碼型”，給這個PlaceOrder寫單元測試 && 程式碼涵蓋範圍要>=70%，光驗證那塊就需要很多

b.      OOP的代碼可以分別給各個class編寫單元測試，且程式碼涵蓋範圍>=70%比較容易能做到