成都创新互联网站制作重庆分公司

Scala中Trait有什么作用

这篇文章主要介绍“Scala中Trait有什么作用”,在日常操作中,相信很多人在Scala中Trait有什么作用问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Scala中Trait有什么作用”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

网站建设哪家好,找创新互联!专注于网页设计、网站建设、微信开发、小程序设计、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了东城免费建站欢迎大家使用!

Inside Scala - 1:Partially applied functions

Partially applied function(不完全应用的函数)是scala中的一种curry机制,本文将通过一个简单的实例来描述在scala中 partially applied function的内部机制。

// Test3.scala  package test   object Test3 {     def sum(x:Int, y:Int, z:Int) = x + y + z        def main(args: Array[String]) {      val sum1 = sum _      val sum2 = sum(1, _:Int, 3)      println(sum1(1,2,3))      println(sum2(2))      List(1,2,3,4).foreach(println);      List(1,2,3,4).foreach(println _)    }   }

在这个代码中 sum _ 表示了一个 新的类型为 (Int,Int,Int)=>Int 的函数,实际上,Scala 会生成一个新的匿名函数(是一个函数对象,Function3),这个函数对象的apply方法会调用 sum 这个对象方法(在这里,是方法,而不是一个函数)。
sum2 是一个 Int => Int的函数(对象),这个函数的apply方法会调用 sum 对象方法。
后面的两行代码都需要访问 println, println是在在Predef对象中定义的方法,在scala中,实际上都会生成一个临时的函数对象,来包装对 println 方法的调用。如果研究一下scala生成的代码,那么可以发现,目前生成的代码中, 对 println, println _生成的代码是重复的,这也说明,目前,所有的你匿名函数基本上没有进行重复性检查。(这可能导致编译生成的的类更大)。

从这里可以得知,虽然,在语法层面,方法(所有的def出来的东西)与函数看起来是一致的,但实际上,二者在底层有区别,方法仍然是不可以直接定位、传值的,他不是一个对象。而仅仅是JVM底层可访问的一个实体。而函数则是虚拟机层面的一个对象。任何从方法到函数的转换,Scala会自动生成一个匿名的函数对象,来进行相应的转换。

所以, List(1,2,3,4).foreach(println) 在底层执行时,并不是获得了一个println的引用(实际上,根本不存在println这个可访问的对象),而是scala自动产生一个匿名的函数,这个函数会调用println。

当然,将一个函数传递时,Scala是不会再做不必要的包装的,而是直接传递这个函数对象了。

Inside Scala - 2: Curry Functions

Curry,在函数式语言中是很常见的,在scala中,对其有特别的支持。

package test

object TestCurry {     def sum(x:Int)(y:Int)(z:Int) = x + y + z     def main(args: Array[String]){       val sum1: (Int => Int => Int) = sum(1)      val sum12: Int => Int = sum(1)(2)      val sum123 = sum(1)(2)(3)      println(sum1(2)(3))      println(sum12(3))      println(sum123)     }   }

在这个例子中, sum 被设计成为一个curried函数,(多级函数?),研究一个函数的实现是很有意思的:

如果看生成的 sum 函数代码,那么,它与 如下编写的
def sum(x:Int, y:Int: z:Int) = x + y + z 是一致的。
而且,如果,你调用sum(1)(2)(3),实际上,scala也并不会产生3次函数调用,而是一次 sum(1,2,3)

也就是说,如果你没有进行 sum(1), sum(1)(2)等调用,那么实际上,上述的代码中根本不会生成额外的函数处理代码。但是,如果我们需要进行一些常用的curry操作时,scala为我们提供了额外的语法级的便利。

Inside Scala - 3: How Trait works

Scala中Trait应该是一个非常强大,但又有些复杂的概念,至少与我,我对trait总是有一些不太明了的地方,求人不如求己,对这些疑问还是自己动手探真的比较好。

还是从一个简单的实例着手。

package test

import java.awt.Point   object TestTrait {     trait Rectangular {      def topLeft: Point      def bottomRight: Point            def left = topLeft.x      def top = topLeft.y      def right = bottomRight.x      def bottom = bottomRight.y      def width = right - left      def height = bottom - top    }        class Rectangle(val topLeft: Point, val bottomRight: Point) extends Rectangular {      override def toString = "I am a rectangle"   }   }

对这段代码,我想问如下的几个问题:
Rectangle是如何继承 Rectangular的行为,如 left, right, width, height的?
Rectangular 对应于Java的接口,那么,相关的实现代码又是如何保存的?
其实,这两个问题是相关的。研究这个问题的最直接的办法莫过于直接分析scalac编译后的结果。
这个类编译后包括:
TestTrait.class 这个类
TestTrait$.class 其实就是 object TestTrait这个对象的类。一个object实际上从属于一个类,scala是对其加后缀$
在这个例子中,TestTrait这个对象实际上并未定义新的属性和方法,因此,并没有包含什么内容
TestTrait$Rectangular.class
对应于代码中的Rectangular这个trait,这实际上是一个接口类。对应的就是这个trait中定义的全部方法。包括topLeft, bottomRight以及后续的实现方法left, width等的接口定义

public interface test.TestTrait$Rectangular extends scala.ScalaObject{   public abstract int height();  public abstract int width();  public abstract int bottom();  public abstract int right();  public abstract int top();  public abstract int left();  public abstract java.awt.Point bottomRight();  public abstract java.awt.Point topLeft();   }

TestTrait$Rectangular$class.class
这个类实际上是trait逻辑的实现类。由于JVM中,接口是不支持任何的实现代码的,因此,scala将相关的逻辑代码编译在这个类中

public abstract class test.TestTrait$Rectangular$class extends java.lang.Object{   public static void $init$(test.TestTrait$Rectangular); // 在这个例子中,没有trait的初始化相关操作    Code:     0:   return  public static int height(test.TestTrait$Rectangular);   // 对应于height = bottom - top这个操作的实现    Code:     0:   aload_0     1:   invokeinterface #17,  1; //InterfaceMethod test/TestTrait$Rectangular.bottom:()I     6:   aload_0     7:   invokeinterface #20,  1; //InterfaceMethod test/TestTrait$Rectangular.top:()I     12:  isub     13:  ireturn

更多的方法并不在此罗列。
首先,这个实现类是抽象的,它不需要被实例化。
所有的trait方法,其实接收一个额外的参数,即 this 对象。对对象的任何的访问,如bottom等操作,实际上是直接调用对象的相应操作。
所有的trait方法,都是static的。
TestTrait$Rectangle.class
这个就是Rectangle这个类的代码了。

// 首先,实现类以implements的方式继承了trait所定义的接口。  public class test.TestTrait$Rectangle extends java.lang.Object implements test.TestTrait$Rectangular,scala.ScalaObject{   // 类的val属性直接对应于一个同名的private字段和相应的读取方法。  private final java.awt.Point bottomRight;   private final java.awt.Point topLeft;   // scala对象比较特殊的是,相应字段的初始化比调用父类构造函数来得更早。也就是说,在Class(arg)中的参数是最早被初始化的。  // 在构造函数后,可以看到,会调用trait的初始化代码。当然,在我们的这个例子中,trait没有任何的初始化行为。  public test.TestTrait$Rectangle(java.awt.Point, java.awt.Point);    Code:     0:   aload_0     1:   aload_1     2:   putfield        #13; //Field topLeft:Ljava/awt/Point;     5:   aload_0     6:   aload_2     7:   putfield        #15; //Field bottomRight:Ljava/awt/Point;     10:  aload_0     11:  invokespecial   #20; //Method java/lang/Object."":()V     14:  aload_0     15:  invokestatic    #26; //Method test/TestTrait$Rectangular$class.$init$:(Ltest/TestTrait$Rectangular;)V     18:  return  // height这个函数是从trait中继承的,在这里,继承体现为对trait实现类的一个调用,同时,将对象本身作为this传递给该函数  public int height();    Code:     0:   aload_0     1:   invokestatic    #39; //Method test/TestTrait$Rectangular$class.height:(Ltest/TestTrait$Rectangular;)I     4:   ireturn

这里不再罗列其他的函数实现,其基本与height函数是相一致的。

理解了以上的逻辑,trait是如何实现将接口和接口实现溶于一体的,应该就非常的清楚了。我以前一直在纳闷一个问题:接口中不能够包含实现代码,那么,难道每次编译继承trait的类时,这写实现的代码是怎么在子类中继承的呢?难道是编译器将这个逻辑复制了一份?如果这样,不仅生成的代码量很大,而且,还有一个问题,那就是,在编译时需要有trait的源代码才行。经过上面的剖析,我们终于知道scala其实有更***的解决之道的:那就是一个trait辅助类。

Inside Scala - 4: Trait Stacks

这个例子摘自 Programming In Scala 这本书第12.5节。本文将从另外一个角度来分析 Stackable Trait的内部原理。

package test

import scala.collection.mutable.ArrayBuffer   object Test7 {     abstract class IntQueue {      def put(x:Int)      def get(): Int    }        class BasicIntQueue extends IntQueue {      private val buf = new ArrayBuffer[Int]      def put(x:Int) { buf += x }      def get() = buf.remove(0)    }     trait Doubling extends IntQueue {      abstract override def put(x:Int) { super.put(2*x) }    }     def main(args: Array[String]) {      val queue: IntQueue = new BasicIntQueue with Doubling      queue.put(1)      queue.put(5)      println( queue.get )      println( queue.get )    }   }

我们来看这一行代码 val queue = new BasicIntQue with Doubling,Scala针对这一行代码干了很多很多的工作,并不是一个简单的操作那么简单
Scala需要新生成一个类型,在我的环境中,这个类叫做:Test7$$anon$1,看看这个代码:
// 新的类以BasicIntQueue为父类,同时实现了Doubling这个trait定义的接口

public final class test.Test7$$anon$1 extends test.Test7$BasicIntQueue implements test.Test7$Doubling{   public test.Test7$$anon$1();    Code:     0:   aload_0     1:   invokespecial   #10; //Method test/Test7$BasicIntQueue."":()V // 父类初始化     4:   aload_0     5:   invokestatic    #16; //Method test/Test7$Doubling$class.$init$:(Ltest/Test7$Doubling;)V // trait辅助类初始化     8:   return  public void put(int);    Code:     0:   aload_0     1:   iload_1     2:   invokestatic    #21; //Method test/Test7$Doubling$class.put:(Ltest/Test7$Doubling;I)V // 这个类使用的是Doubling提供的版本     5:   return  public final void test$Test7$Doubling$$super$put(int); // Doubling所需要的super的版本    Code:     0:   aload_0     1:   iload_1     2:   invokespecial   #29; //Method test/Test7$BasicIntQueue.put:(I)V     5:   return  }

我们来分析一下Doubling这个trait的实现

public interface test.Test7$Doubling extends scala.ScalaObject{   public abstract void put(int);  // 这个是trait中实现的方法   public abstract void test$Test7$Doubling$$super$put(int); // 这个是这个trait 额外依赖的方法   }   // Doubling这个trait的辅助类  public abstract class test.Test7$Doubling$class extends java.lang.Object{  public static void $init$(test.Test7$Doubling);    Code:     0:   return  public static void put(test.Test7$Doubling, int);    Code:     0:   aload_0     1:   iconst_2     2:   iload_1     3:   imul     4:   invokeinterface #17,  2; //InterfaceMethod test/Test7$Doubling.test$Test7$Doubling$$super$put:(I)V  // 这也是 Doubling这个接口中需要 super.init这个方法的原因。     9:   return  }

由此可见,编译器在处理 val queue: IntQueue = new BasicIntQueue with Doubling这一行代码时,需要确定类、Trait的先后顺序。这也是理解Trait的最为复杂的一环。后续,我将就这个问题进行分析。

Inside Scala - 5: Trait Stacks

继续上一个案例,现在我们将Trait的链搞得更长一些:

trait Incrementing extends IntQueue {  abstract override def put(x: Int) { super.put(x + 1) }  }  trait Filtering extends IntQueue {  abstract override def put(x: Int) {  if (x >= 0) super.put(x)  }  }   val queue: IntQueue = new BasicIntQueue with Incrementing with Filtering

新的类如何呢?当我们调用 queue的 put方法时,这个的先后顺序究竟如何呢?还是看看生成的代码:

public final class test.Test7$$anon$1 extends test.Test7$BasicIntQueue implements test.Test7$Incrementing,test.Test7$Filtering{   // 初始化的顺序:先父类、再Incremeting、再Filtering,这个顺序与源代码的顺序是一致的。  public test.Test7$$anon$1();    Code:     0:   aload_0     1:   invokespecial   #10; //Method test/Test7$BasicIntQueue."":()V     4:   aload_0     5:   invokestatic    #16; //Method test/Test7$Incrementing$class.$init$:(Ltest/Test7$Incrementing;)V     8:   aload_0     9:   invokestatic    #21; //Method test/Test7$Filtering$class.$init$:(Ltest/Test7$Filtering;)V     12:  return  // put 方法实际使用的是 Filtering这个Trait的put  public void put(int);    Code:     0:   aload_0     1:   iload_1     2:   invokestatic    #34; //Method test/Test7$Filtering$class.put:(Ltest/Test7$Filtering;I)V     5:   return  // Filtering Trait的父实现是Incremeting trait  public final void test$Test7$Filtering$$super$put(int);    Code:     0:   aload_0     1:   iload_1     2:   invokestatic    #38; //Method test/Test7$Incrementing$class.put:(Ltest/Test7$Incrementing;I)V     5:   return  // incrementing的父实现是父类的实现。  public final void test$Test7$Incrementing$$super$put(int);    Code:     0:   aload_0     1:   iload_1     2:   invokespecial   #26; //Method test/Test7$BasicIntQueue.put:(I)V     5:   return  }

因此,要理解这个过程,可以这么来分析:val queue: IntQueue = new BasicIntQueue with Incrementing with Filtering
首先初始化的是BasicIntQueue
在这个基础上叠加 Incrementing,super.put引用的是BasicIntQueue的put方法
再在叠加后的基础上叠加 Filtering,super.put引用的是 Incrementing的put方法
叠加后的结果就是***的版本。put引用的是Filtering的put方法
因此,初始化的顺序是从左至右,而方法的可见性则是从右至左(可以理解为上面的叠加关系,叠加之后,上面的trait具有更大的优先可见性。

Inside Scala - 6:Case Class 与 模式匹配

本文将尝试对Case Class是如何参与模式匹配的进行剖析。文中的代码还是来自 Programming In Scala一书。

abstract class Expr;  case class Var(name: String) extends Expr;  case class Number(num: Double) extends Expr;  case class UnOp(operator: String, arg: Expr) extends Expr;  case class BinOp(operator:String, left: Expr, right: Expr) extends Expr;

这里我们先来看一个最为简单的模式匹配

some match {    case Var(name) => println("a var with name:" + name)  }


这几行的代码编译后等效于:

if(some instanceof Var)  {      Var temp21 = (Var)some;      String name = temp21.name();      if(true)      {          name = temp22;          Predef$.MODULE$.println((new StringBuilder()).append("a var with name:").append(name).toString());      } else     {          throw new MatchError(some.toString());      }  } else {      throw new MatchError(some.toString());  }


如果从生成的代码的角度上来看,Scala生成的代码质量并不高,其中的 if(true) else 的那个部分就有明显的废代码。(不过,这个对运行效率的影响到时几乎可以忽略,只是编译后的字节码倒是没理由的多了几分)。
上面的这个模式匹配仅仅是匹配一个类型。因此,其对应的java原语就是 instanceof 检测。

让我们更进一步, 看看如下的例子:

some match {    case Var("x") => println("a var with name:x")  }

这个模式匹配不仅匹配类型,还要匹配构造器中的name属性为 "x"常量。这里我就不在福州 Scala生成的字节码了,而是简单的翻译一下:
if( some instanceof Var)  -- 类型检查
var.name() == "x"             -- 检查 对象的 name 属性是否等于 "x",编译器非常清楚的指导 Case Class的每一个构造参数所对应的字段名称。

更进一步,让我们看看一个更复杂的模式匹配:嵌套的对象。

some match {    case BinOp("+", Var("x"), UnOp("-", Number(num))) => println("x - " + num)  }

这个逻辑其实也是上面的一个嵌套:
some instanceof BinOp
some.operator == "+"  编译器进行了特殊的null检测,以防止这个操作出现NPE
some.left instanceof Var
some.left.name == "x"
some.right instanceof UnOp
some.right.operator == "-"
some.right.arg instanceof Number
......
实际上,Scala的模式匹配确实为我们干了很多很多的事情,这也使得在很多的情况下,使用scala的模式匹配为我们提供了一个非常安全的(不用担心大量的Null检查),以及非常复杂的匹配操作。当然,与更复杂的模式匹配相比(譬如,规则引擎其实也是一个模式匹配的引擎),Scala的模式匹配还是相对比较简单的。

这里简单的补充一下 Scala中的几种模式:
1、通配符模式。 也就是说使用 case _ => 来匹配所有的东西。或者,case Var(_) 来对局部进行通配。
2、常量匹配。譬如上述的Var("x") ,其中,"x"就是一个常量。常量除了文字常量外,还可以使用以大写字母开头的scala变量,或者`varname`形式的引用。
3、变量匹配。一个变量匹配实际上匹配任何的类型,并同时赋予其一个变量名。
4、构造函数匹配。匹配一个给定的类型,并且嵌套的对其参数进行匹配。参数可以是通配符模式、常量、变量或者子构造函数匹配
5、对于List类型, _*可以匹配剩余的全部元素。
6、Tuple匹配。(a,b,c)
7、类型匹配。对于java对象,由于并不适合Scala的Case Class模型,因此,可以使用类型进行匹配。在这种情况下,与构造子匹配是不同的。

再摘一段我以前编写的使用scala来编写应用程序的逻辑代码,让我们看看模式匹配在商业应用中的使用:

_req.transType match {        case RechargeEcp | RechargeGnete | FreezeToAvailable => // 充值类交易          assert(_req.amount > 0, "金额不正确")        case DirectPay | AvailableToFreeze =>    // 支付、冻结类交易          assert(_req.amount < 0, "金额不正确")        case _ =>              assert(false, "无效交易类型")      }            val _account = queryEwAccount(_req.userId)      assert(_account != null, "用户尚未开通电子钱包")            var _accAvail, _accFreeze: EWSubAccount = null     var _total: BigDecimal = _req.amount      _account.subAccounts.find(_.subTypeCode==Available) match {        case Some(x) =>  _accAvail = x;    _total += x.balance        case None =>      }      _account.subAccounts.find(_.subTypeCode==Freeze) match {        case Some(x) =>  _accFreeze = x;    _total += x.balance        case None=>      }

这个仅仅是一个很简单的应用,试想使用Java的if/else或者switch来进行相同的代码,你不妨看看代码量会增加多少?可读性又会如何呢?

Scala Actor是一种借鉴于Erlang的进程消息机制的并发编程模式,由于Java中不存在Erlang的进程的概念,因此,Scala的Actor在隔离性上是不如Erlang的,譬如,在Erlang中,可以有效的终止一个进程,不仅仅无需担心死锁(根本没有锁),也可以马上释放掉改进程的内存,这种隔离性在某种程度上是更接近于操作系统的进程的。在Java的世界里暂时没有等效的替代品。

(题外话,最近在我们的Open Service Platform中集成了一个类似于操作系统定时调度的机制,可以定时执行一些任务,但是***,我们仍然决定将部分非交易相关的定时任务,主要是一些日志分析类、管理性批量处理等定时任务放到操作系统上进行调度,毕竟操作系统提供了一个更好的虚拟机,在OSGi层面仍然是有限的隔离,哪一天JVM能够提供像操作系统的隔离特性,那么,操作系统就真的不重要了)。

本文将对actor的机制进行简单的分析,以帮助加强对actor的理解。

package learn.actor   object Test1 extends Application {     import scala.actors.Actor._     val actor1 = actor {       println("i am in " + Thread.currentThread)       while(true) {         receive {           case msg => println("recieve msg:" + msg + " In " + Thread.currentThread);         }       }     }         val actor2 = actor {       println("i am in " + Thread.currentThread)       while(true) {         receive {           case msg: String => println("recieve msg:" + msg.toUpperCase + " In " + Thread.currentThread);         }       }     }         actor1 ! "Hello World"    actor2 ! "Hello World"    actor1 ! "ok"    actor2 ! "ok"      }

运行的结果是:

i am in Thread[pool-1-thread-1,5,main]  i am in Thread[pool-1-thread-2,5,main]  recieve msg:HELLO WORLD In Thread[pool-1-thread-2,5,main]  recieve msg:Hello World In Thread[pool-1-thread-1,5,main]  recieve msg:OK In Thread[pool-1-thread-2,5,main]  recieve msg:ok In Thread[pool-1-thread-1,5,main]

从这个例子来看,actor1和actor2实际上是两个独立的Java线程,任何线程可以将消息以 ! 的方式发给给这个线程进行处理。由于采用消息的方式来进行通信,因此,线程与线程之间无需采用Java的notify/wait机制,而后者是建立在锁的基础之上的。有关于这一点,我不在本文只进行深入的分析了。(有必要的话,我会再写一个帖子来说明)。

那么 Scala Actor 的底层基础是什么呢?与Java的notify/wait就完全没有关系吗?我们将重点分析actor的三个方法:!, receive, react

1、Scala Actor的send(外部调用者发送一个消息给当前actor)和receive(当前actor接收一个消息),这两个操作是同步的(synchronized),也就是说,不可同时进入。(客观的说,这一块应该有很大的优化空间,应该采用乐观锁的机制,可能会有更好的效率,一来,send/receive操作本身都是很快速的操作,即便在出现冲突的情况下,使用乐观锁也可以降低线程切换引起的开销,而且,在大部分情况下,send操作与receive操作引发冲突的可能性并不是很大的。也就是说,在很大的程度上,send和receive还可以有更好的并行性,不知道后续的scala版本是否会进行优化。)

2、执行send操作时,如果当前actor正在等待这个消息(指actor自身已经在receive、react并且期待这个消息的情况下),那么原来的等待将会马上执行,否则,消息会进入到actor的邮箱,等待下次receive/react的处理。这种模式相较于全部放入邮箱更加有效。它避免了一次在邮箱上的同步等待。

3、当执行receive操作时,actor会检查对象的邮箱,如果有匹配的消息的话,则会马上返回该消息进行处理,否则会处在等待状态(当前线程阻塞,采用的是wait原语)当匹配的消息到达时,也是采用notify原语通知等待线程继续actor的处理的。

4、react与receive不同的是,react从不返回。这个在Java的编程世界里,好像还没有看到类似的东西,该如何理解它呢:

react(f: ParticialFunction[Any,Unit]) 首先检查actor的邮箱,如果有符合f的消息,则马上提取该消息,并且在一个ExecutionPool中调度执行f。(因此,f的执行肯定不在请求react这个线程中执行的。当前的调用react的线程,将产生一个 SuspendActorException,从而中断一般的执行过程。(也就是说文档中说的不返回的概念)

如果当前邮箱中没有消息,react将登记一个Continuation对象,将等待的消息(一个等待给定消息的函数)、获得消息后需要继续进行的处理在actor中进行登记,而后,当前线程会产生一个SuspendActorException,中断处理(从而是将当前线程归还到线程池)。

当消息到达(通过send)时,send将检查等待消息的Continuation,如过匹配的话,则会在线程池中的选择一个线程来执行f函数。在f处理完成一个消息后,一般的,它会再次调用 react来处理下一个消息,将再次重复这个过程。

应该说,scala的这个设计是非常精巧,也非常有效的,但这对Java开发程序员来说,就意味着一个新的挑战:看上去的一个函数体,实际上其中的代码不仅是执行不连续的(如closure可能会延迟、重复多次的被调用),甚至可能是在不同的线程中被执行的。

从这个概念上来看,scala的actor并不对应于Java的线程,相反,可以理解为一个行为执行者,是一个有上下文的非操作系统线程,语义其实更接近于现实的一个载体。这个与Erlang的进程还是有很明显的语义上的区别的。从上述的分析中,或许如果切换到乐观锁的机制,Scala的并发效率还能有更进一步的提升。

到此,关于“Scala中Trait有什么作用”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!


分享标题:Scala中Trait有什么作用
本文来源:http://cxhlcq.com/article/jiohcj.html

其他资讯

在线咨询

微信咨询

电话咨询

028-86922220(工作日)

18980820575(7×24)

提交需求

返回顶部