• 生活中的设计模式


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

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

     

    案例一

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

    流程

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

    初始版

     

       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();

    未完待续…

  • 相关阅读:
    31、状态模式(详解版)
    33、中介者模式(详解版)
    36、备忘录模式(详解版)
    34、迭代器模式(详解版)
    30、责任链模式(职责链模式)详解
    29、命令模式(详解版)
    32、观察者模式(Observer模式)详解
    37、解释器模式(详解版)
    35、访问者模式(Visitor模式)详解
    28、策略模式(策略设计模式)详解
  • 原文地址:https://www.cnblogs.com/hankskfc/p/3406646.html
Copyright © 2020-2023  润新知