加入收藏 | 设为首页 | 会员中心 | 我要投稿 河北网 (https://www.hebeiwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 建站 > 正文

换一种角度:从架构层面来看设计模式

发布时间:2019-07-22 20:36:25 所属栏目:建站 来源:架构思维
导读:大部门讲授计划模式的书可能文章,都是从代码层面来讲授计划模式,看的时辰都懂,可是到真正用的时辰,照旧理不清、想不明。 本文实行从架构层面来聊一聊计划模式。通过将行使计划模式的代码和不行使计划模式的代码别离放到架构中,来看看计划模式对架构所
副问题[/!--empirenews.page--]

大部门讲授计划模式的书可能文章,都是从代码层面来讲授计划模式,看的时辰都懂,可是到真正用的时辰,照旧理不清、想不明。

本文实行从架构层面来聊一聊计划模式。通过将行使计划模式的代码和不行使计划模式的代码别离放到架构中,来看看计划模式对架构所发生的影响。

一样平常模式讲授套路

一样平常讲授计划模式的套路是:

  • 声名模式的意图
  • 声名模式的合用场景
  • 给出模式的类布局
  • 给出对应的代码示例

以计策模式为例:

意图:界说一系列的算法,把它们一个个封装起来, 而且使它们可彼此替代。本模式使得算法可独立于行使它的客户而变革。

合用性:

  • 很多相干的类仅仅是举动有异。「计策」提供了一种用多个举动中的一个举动来设置一个类的要领。
  • 必要行使一个算法的差异变体。譬喻,你也许会界说一些反应差异的空间/时刻衡量的算法。当这些变体实现为一个算法的类条理时,可以行使计策模式。
  • 算法行使客户不该该知道的数据。可行使计策模式以停止袒露伟大的、与算法相干的数据布局。
  • 一个类界说了多种举动, 而且这些举动在这个类的操纵中以多个前提语句的情势呈现。将相干的前提分支移入它们各自的Strategy类中以取代这些前提语句。

类布局:

从架构层面看计划模式

示例代码:

  1. public class Context { 
  2.  
  3.  //持有一个详细计策的工具 
  4.  private Strategy strategy; 
  5.  
  6.  /** 
  7.  * 结构函数,传入一个详细计策工具 
  8.  * @param strategy 详细计策工具 
  9.  */ 
  10.  public Context(Strategy strategy){ 
  11.  this.strategy = strategy; 
  12.  } 
  13.   
  14.  /** 
  15.  * 计策要领 
  16.  */ 
  17.  public void invoke(){ 
  18.  strategy.doInvoke(); 
  19.  } 
  20.  
  21. public interface Strategy { 
  22.  
  23.  /** 
  24.  * 计策要领 
  25.  */ 
  26.  public void doInvoke(); 
  27.  
  28. public class StrategyA implements Strategy { 
  29.  
  30.  @Override 
  31.  public void doInvoke() { 
  32.  System.out.println("InvokeA"); 
  33.  } 
  34.  
  35. public class StrategyB implements Strategy { 
  36.  @Override 
  37.  public void doInvoke() { 
  38.  System.out.println("InvokeB"); 
  39.  } 

从上面的讲授,你能领略计策模式吗?你是否有如下的一些疑问?

  • 行使计策模式和我直接写if-else详细的上风在那边?
  • if-else不是挺简朴的,为什么要多写这么多的类?
  • 怎样将Strategy给配置到Context中?
  • 我该怎样判定将哪个实现配置给Context?照旧ifelse?!那拆成这么多的类不是脱裤子放屁吗?

将模式放入架构中

发生这些疑问的缘故起因,是我们在孤独的看计划模式,而没有把计划模式放到现实的场景中。

当我们将其放到现实项目中时,我们现实是必要一个客户端来组装和挪用这个计划模式的,如下图所示:

从架构层面看计划模式  
  1. public class Client { 
  2.   
  3.  public static void main(String[] args) { 
  4.  Strategy strategy; 
  5.  if("A".equals(args[0])) { 
  6.  strategy = new StrategyA(); 
  7.  } else { 
  8.  strategy = new StrategyB(); 
  9.  } 
  10.  Context context = new Context(strategy); 
  11.  context.invoke(); 
  12.  }  

作为较量,这里也给出直接行使ifelse时的布局和代码:

从架构层面看计划模式  
  1. public class Client { 
  2.  public static void main(String[] args) { 
  3.  Context context = new Context(args[0]); 
  4.  context.invoke(); 
  5.  } 
  6.  
  7. public class Context { 
  8.  public void invoke(String type) { 
  9.  if("A".equals(type)) { 
  10.  System.out.println("InvokeA"); 
  11.  } else if("B".equals(type)) { 
  12.  System.out.println("InvokeB"); 
  13.  } 
  14.  } 

乍看之下,行使ifelse越发的简朴明白,不外别急,下面我们来比拟一下两种实现方法的区别,来详细看看计划模式所带来的上风。

界线差异

(编辑:河北网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读