设计模式这个概念应该大家都很不陌生了。这么多模式当中其实真正用到的，实际上很少。正由于用的少导致我们刚刚开始学习的时候相当困难！然而呢，实际项目中由架构师设计的框架都是充满了设计模式的气息，让我们这些“菜鸟”望而生畏，总是被Leader推着走。

    接下来我就从我的一些项目案例来讲下我理解的所谓模式。

 

 

案例一

   淘宝买过东西的人都应该知道一个流程：“拍下商品”->“付款到支付宝”->“卖家发货”->“确认收货”->“评价”。

 

作为“菜鸟”的我，一开始想到的代码段为：

 

初始版

 

class="alt">   1:   if ("拍下商品")

   2:   {

   3:                  //更新为拍下商品

   4:                  //...一些业务操作

   5:   }else if ("付款到支付宝")

   6:   {

   7:                  //更新为拍下商品

   8:                  //...一些业务操作

   9:   }

  10:   ....

 

问题就随之而来了，由于每一步操作（即if操作）我们都有很多业务上的操作或者业务逻辑。那么这个方法的行数就不敢恭维了。

 

当你发现去写某个方法或者修改某个方法心里用的很不爽的时候，那么就得考虑用些OOP思想去规避这些问题。

 

修改版本

要用OOP思想优化代码，首先要面临的是一个你看这个业务的观察点。观察点的不同，设计出的框架也随之不同。

作为“菜鸟”的我找到了两个切入点：

• 将“每一个过程”作为主要观察点。
• 将“这整个过程”作为主要观察点。

第一个的代码段为：

   1:  public class 拍下商品

   2:   {

   3:        public void DoSomething()

   4:        {

   5:        }

   6:    }

   7:   

   8:  public class 付款到支付宝

   9:   {

  10:        public void DoSomething()

  11:        {

  12:        }

  13:    }

  14:   

  15:  ...接下来类似

 

第二个代码段为：

   1:      class 过程

   2:      {

   3:          public void 拍下商品()

   4:          {

   5:          }

   6:   

   7:          public void 付款到支付宝()

   8:          {

   9:          }

  10:   

  11:        ...类似操作

  12:   

  13:          public void DoSomething()

  14:          {

  15:              拍下商品();

  16:              付款到支付宝();

  17:              ....类似操作

  18:          }

  19:      }

 

从第一个代码段来分析：“过程的链接”职责变为了“调用者”。然而第二段代码段“过程的链接”的职责是框架担任的。

具体选取那种得结合项目设计和业务需求选取。

 

优化第一个代码段（“将“每一个过程”作为主要观察点。”）

首先我们发下我们“每个过程”都会做一些“固定的操作”即（“DoSomething”操作），那么由此我们就可以提取个接口IAction

   1:  public interface IAction

   2:  {

   3:         void DoSomething();

   4:  }

如果当业务不断的扩大的话，可能DoSomething这个方法又会遇到一开始的弊端“方法过于肥大”，那么又应该对该方法进行OOP优化。然后我们发现我们似乎又回到了最初的问题，那么这里按照上面我的这种观察点的选取又会出现两种。

一个以“每个过程”为观察点，一个以“整个过程”为观察点。

 

这里我们先以“每个过程”为观察点为例子。

 

 

DoSomething方法可以被分为DoA，DoB，DoC … 。按照上面的分析以“每个过程”为观察点，“过程链接”职责要变为“调用者”维护。换句话说：

   1:  public void DoSomething()

   2:  {

   3:           DoA();

   4:           DoB();

   5:           DoC();

   6:           ...

   7:  }

 

接着我们发下“每个过程”都会上面类似的代码段，因为都实现了“IAction”接口。这样的话我们的接口感觉就定义的有点“胖”了，修改后的接口为：

   1:  public interface IAction

   2:  {

   3:          void DoA();

   4:          void DoB();

   5:          void DoC();

   6:         ....

   7:  }

然后我们在来看看一开的代码变成什么样子了：

   1:  public class 拍下商品:IAction

   2:  {

   3:       public void DoA()

   4:       {

   5:             //....

   6:       }

   7:   

   8:       public void DoB()

   9:       {

  10:             //....

  11:       }

  12:   

  13:       public void DoC()

  14:       {

  15:             //....

  16:       }

  17:   

  18:  }

 

那这样就剩下一个问题了：“如何把DoA，DoB，DoC”串联起来，即维护最外层的“调用链”职责。

   1:  public class ActionManager

   2:      {

   3:          private IAction _action = null;

   4:          public ActionManager(IAction action)

   5:          {

   6:              _action = action;

   7:          }

   8:   

   9:          public void DoSomething()

  10:          {

  11:              _action.DoA();

  12:              _action.DoB();

  13:              _action.DoC();

  14:          }

  15:      }

那么使用方式为：

   1:  var actionMgr = new ActionManager(拍下商品);

   2:   

   3:  actionMgr.DoSomething();

 

未完待续…