akka设计模式系列-Chain模式

  链式调用在很多框架和系统中经常存在,算不得上是我自己总结的设计模式,此处只是简单介绍在Akka中的两种实现方式。我在这边博客中简化了链式调用的场景,简化后也更符合Akka的设计哲学。

trait Chained{
  def receive:Receive = Actor.emptyBehavior
}
trait IntReceiveChained1 extends Chained{
  override def receive:Receive = super.receive orElse {
    case i:Int => println(s"IntReceiveChained1 receive Int $i")
  }
}
trait IntReceiveChained extends Chained{
  override def receive:Receive = super.receive orElse {
    case i:Int => println(s"IntReceive receive Int $i")
  }
}
trait StringReceiveChained extends Chained {
  override def receive:Receive = super.receive orElse {
    case i:Int => println(s"StringReceive receive Int $i")
    case s:String => println(s"StringReceive receive String $s")
  }
}
class ChainedActor extends Actor with IntReceiveChained with StringReceiveChained with IntReceiveChained1 {
  override def receive:Receive = super.receive orElse {
    case any =>
      println(s"ChainingActor receive any $any")
  }
}
object ChainingPattern1 {
  def main(args: Array[String]): Unit = {
    val system = ActorSystem("ChainingPattern1",ConfigFactory.load())
    val chainingActor = system.actorOf(Props(new ChainedActor),"ChainedActor")
    chainingActor ! 123
    chainingActor ! "test"
  }
}

输出:

IntReceive receive Int 123
StringReceive receive String test

  上面这一种实现方式跟akka没有太大关系,是用scala的trait实现的。在类中调用多个Trait中都有的方法时,首先会从最右边的Trait的方法开始执行,然后依次向左执行,形成一个调用条。这个相当于设计模式中的责任链模式的一种具体实现依赖。只不过是用orElse来实现,以保证每种类型的消息都只被处理一次。我们也可以把orElse替换掉,根据条件判断是否继续调用后续函数,这个需要我们根据业务场景来选择,我就不再展开了。

  

trait Chaining { self => Actor
  private var chainedReceives = List.empty[Receive]
  def registerReceive( newReceive:Receive ): Unit = {
    chainedReceives = newReceive :: chainedReceives
  }
  def receive:Receive = chainedReceives.reduce(_ orElse _)
}
trait IntReceive extends Chaining{
  registerReceive{
    case i:Int => println(s"IntReceive receive Int $i")
  }
}
trait StringReceive extends Chaining {
  registerReceive{
    case s:String => println(s"StringReceive receive String $s")
  }
}
class ChainingActor extends Actor with IntReceive with StringReceive{
}
object ChainingPattern2 {
  def main(args: Array[String]): Unit = {
    val system = ActorSystem("ChainingPattern2",ConfigFactory.load())
    val chainingActor = system.actorOf(Props(new ChainingActor),"chainingActor")
    chainingActor ! 123
    chainingActor ! "test"
  }
}

输出:

IntReceive receive Int 123
StringReceive receive String test

  这种实现方式是将Receive函数注册到一个列表中,通过reduce把处理函数orElse串起来。与第一种方式一样,对相同的类型也都是只匹配一次。此处只是为了简化设计模式的介绍,读者也都可以根据需求修改对chainedReceives的处理方式,比如所有函数都匹配一遍,或者根据业务条件选择性的匹配。

  Akka的Chain模式并不常用,但非常有用。有了它,我们就可以自由组合对消息的处理过程了。如果某个receive需要对大量的消息进行处理,我们可以对消息进行分类,创建不同的链式函数去匹配处理,可以做到高内聚低耦合的效果。

原文地址:https://www.cnblogs.com/gabry/p/9303712.html

时间: 2024-08-28 16:39:17

akka设计模式系列-Chain模式的相关文章

akka设计模式系列-消息模型(续)

在之前的akka设计模式系列-消息模型中,我们介绍了akka的消息设计方案,但随着实践的深入,发现了一些问题,这里重新梳理一下设计方法,避免之前的错误.不当的观点给大家带来误解. 命令和事件 我们仍然把akka中的消息分为命令和事件两大类,但二者的具体含义和实现有一点变化.“命令,是指一个actor给另外一个actor发送指令做相关的业务逻辑:事件,则是actor对某个命令的响应结果,或者对其他事件的响应结果”.之前是这样定义的,但在具体的实践过程中发现了一些问题. 比如,命令如何归类?是根据命

PHP设计模式系列 - 外观模式

外观模式 通过在必需的逻辑和方法的集合前创建简单的外观接口,外观设计模式隐藏了调用对象的复杂性. 外观设计模式和建造者模式非常相似,建造者模式一般是简化对象的调用的复杂性,外观模式一般是简化含有很多逻辑步骤和方法调用的复杂性. 应用场景 设计一个User类,里面有getUser获取用户信息接口 在使用getUser这个接口的时候,需要设置用户的用户名和用户年龄 所 以在正常情况下,调用getUser接口,需要先实例化User类,然后设置用户信息,最后才调用getUser方法,这个过程是复杂的,如

akka设计模式系列-actor锚定

actor锚定模式是指使用actorSelection对acor进行锚定的设计模式,也可以说是一个对actor的引用技巧.在某些情况下,我们可能需要能够根据Actor的path锚定对应的实例.简单来说就是,无论actor是因为异常导致的restart还是用户主动stop,然后再重新actorOf,只要actor的路径和name相同,我们都希望把消息发送给改Actor的一个实例.那我们来看一下actorSelection和ActorRef的使用区别. class AnchorActor exten

PHP设计模式系列 - 委托模式

委托模式 通过分配或委托其他对象,委托设计模式能够去除核心对象中的判决和复杂的功能性. 应用场景 设计了一个cd类,类中有mp3播放模式,和mp4播放模式 改进前,使用cd类的播放模式,需要在实例化的类中去判断选择什么方式的播放模式 改进后,播放模式当做一个参数传入playList函数中,就自动能找到对应需要播放的方法. 代码:cd类,未改进之前,选择播放模式是一种痛苦的事情 <?php //委托模式-去除核心对象中的判决和复杂的功能性 //使用委托模式之前,调用cd类,选择cd播放模式是复杂的

PHP设计模式系列 - 工厂模式

工厂模式 提供获取某个对象实例的一个接口,同时使调用代码避免确定实例化基类的步骤. 工厂模式 实际上就是建立一个统一的类实例化的函数接口.统一调用,统一控制. 工厂模式是php项目开发中,最常用的设计模式,一般会配合单例模式一起使用,来加载php类库中的类. 应用场景 我们拥有一个Json类,String类,Xml类. 如果我们不使用工厂方式实例化这些类,则需要每一个类都需要new一遍,过程不可控,类多了,到处都是new的身影 引进工厂模式,通过工厂统一创建对象实例. 代码: <?php //工

Android设计模式系列--模板方法模式

模板方法,和单例模式是我认为GOF的23中最简单的两种模式.但是我个人对模板方法的经典思想特别推崇,虽然模板方法在大对数情况下并不被推荐使用,但是这种通过父类调用子类的方法,使用继承来改变算法的一部分,是面向对象的一种基本认识.打比方说父亲有很多理想,就行医救人吧,但是父亲医术不行,只能靠儿子,儿子长大后遵从父亲大志,春风拂面,妙手回春,实现了父亲的理想,儿子做的事情早在出生前就定下来了,是父亲之前久定好的模板.认识到模板方法的这种思想,父类可以让未知的子类去做它本身可能完成的不好或者根本完成不

Android设计模式系列--原型模式

CV一族,应该很容易理解原型模式的原理,复制,粘贴完后看具体情况是否修改,其实这就是原型模式.从java的角度看,一般使用原型模式有个明显的特点,就是实现cloneable的clone()方法.原型模式,能快速克隆出一个与已经存在对象类似的另外一个我们想要的新对象. 1.意图用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.热门词汇:克隆 深拷贝 浅拷贝 2.结构图和代码它的结构图非常简单,我们以Intent为例子: Intent的clone方法非常简单: @Override pu

Android设计模式系列-组合模式

Android中对组合模式的应用,可谓是泛滥成粥,随处可见,那就是View和ViewGroup类的使用.在android UI设计,几乎所有的widget和布局类都依靠这两个类.组合模式,Composite Pattern,是一个非常巧妙的模式.几乎所有的面向对象系统都应用到了组合模式. 1.意图将对象View和ViewGroup组合成树形结构以表示"部分-整体"的层次结构(View可以做为ViewGroup的一部分).组合模式使得用户对单个对象View和组合对象ViewGroup的使

PHP设计模式系列 - 解释器模式

解释器模式 解释器模式 用于分析一个实体的关键元素,并且针对每个元素提供自己的解释或相应动作.解释器模式非常常用,比如PHP的模板引擎 就是非常常见的一种解释器模. 代码: <?php //解释器模式 用于分析一个实体的关键元素,并且针对每个元素提供自己的解释或相应动作 //解释器模式非常常用,比如PHP的模板引擎 就是非常常见的一种解释器模式 class template { private $left = '<!--{'; private $right = '}-->'; publi