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=newTransactionScope())             {                 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(OrderInfoorderInfo)         {             throw new NotImplementedException();         }           private void GenerateNewOrderPdf(OrderInfoorderInfo)         {             throw new NotImplementedException();         }     }

上面这段代码就是Martin folwer所说的”事务脚本模式”，即：一个业务方法写在一个函数里，一大块从头到尾写完。

 

如果想以面向对象方式来写，该如何写呢？答案是（我目前个人认为…哈哈）：画出序列图，再进行编码。

因为使用序列图能够帮助找到各个对象、以及各对象间的通信方法，如下：

这个图貌似比较复杂，因此只有当系统比较复杂时（业务逻辑）才会选择用面向对象的方式来拆分各个对象，好处有：

1.       各个对象其实就是关注点分离，因此维护方便

a.       比如验证那里，修改起来非常有针对性，很容易定位要修改哪个类

b.      计算价格那里也是，很容易定位到需要修改的地方

2.       单元测试时，可以单独测试各个类，而不用给PlaceOrder写无数的测试函数（分而治之）

a.       如果是“事务脚本型”，给这个PlaceOrder写单元测试 && 代码覆盖率要>=70%，光验证那块就需要很多

b.      OOP的代码可以分别给各个class编写单元测试，且代码覆盖率>=70%比较容易能做到

O(∩_∩)O~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

致力于为欧美企业提供IT综合服务的软件商 
O(∩_∩)O~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~