計算機專業(yè)畢業(yè)設(shè)計外文翻譯--面向java開發(fā)人員的scala指南類操作

1、<p>　　來自：think in java （3）</p><p><b>　　外文原文</b></p><p>　　The busy Java developer's guide to Scala: Class action</p><p>　　It makes sense for Java? developers to

2、use objects as a first point of reference for understanding Scala. In this second installment of The busy Java developer's guide to Scala series, Ted Neward follows a basic premise of language measurement: that the p

3、ower of a language can be measured in direct relation to its ability to integrate new facilities -- in this case, support for complex numbers. Along the way you'll see some interesting tidbits related to class defini

4、tions and usage in Scala. In </p><p>　　Scala's functional programming features are compelling, but they're not the only reason Java developers should be interested in the language. In fact, Scala ble

5、nds functional concepts and object orientation. In order to let the Java-cum-Scala programmer feel more at home, it makes sense to look at Scala's object features and see how they map over to Java linguistically. Bea

6、r in mind that there isn't a direct mapping for some of these features, or in some cases, the "mapping" is more of an analog</p><p>　　Scala has class(es), too</p><p>　　Rather than

7、embark on a lengthy and abstract discussion of the class features that Scala supports, let's look at a definition for a class that might be used to bring rational number support to the Scala platform (largely swiped

8、from "Scala By Example" -- see Resources):</p><p>　　Listing 1. rational.scala</p><p>　　While the overall structure of Listing 1 is lexically similar to what you've seen in Java cod

9、e over the last decade, some new elements clearly are at work here. Before picking this definition apart, take a look at the code to exercise the new Rational class:</p><p>　　Listing 2. RunRational</p>

10、<p>　　What you see in Listing 2 isn't terribly exciting: I create a couple of rational numbers, create two more Rationals as the addition and subtraction of the first two, and echo everything to the console. (

11、Note that Console.println() comes from the Scala core library, living in scala.*, and is implicitly imported into every Scala program, just as java.lang is in Java programming.)</p><p>　　How many ways shall

12、I construct thee?</p><p>　　Now look again at the first line in the Rational class definition:</p><p>　　Listing 3. Scala's default constructor</p><p>　　Although you might think y

13、ou're looking at some kind of generics-like syntax in Listing 3, it's actually the default and preferred constructor for the Rational class: n and d are simply the parameters to that constructor.</p><p

14、>　　Scala's preference for a single constructor makes a certain kind of sense -- most classes end up having a single constructor or a collection of constructors that all "chain" through a single construct

15、or as a convenience. If you wanted to, you could define more constructors on a Rational like so:</p><p>　　Listing 4. A chain of constructors</p><p>　　Note that Scala's constructor chain does

16、 the usual Java-constructor-chaining thing by calling into the preferred constructor (the Int,Int version).</p><p>　　Details, (implementation) details...</p><p>　　When working with rational numb

17、ers, it helps to perform a bit of numerical legerdemain: namely that of finding a common denominator to make certain operations easier. If you want to add 1-over-2 (also known as "one-half") to 2-over-4 (also k

18、nown as "two-fourths"), the Rational class should be smart enough to realize that 2-over-4 is the same as 1-over-2, and convert it accordingly before adding the two together.</p><p>　　This is the p

19、urpose of the nested private gcd() function and g value inside of the Rational class. When the constructor is invoked in Scala, the entire body of the class is evaluated, which means g will be initialized with the greate

20、st common denominator of n and d, and then used in turn to set n and d appropriately.</p><p>　　Looking back at Listing 1, it's also fairly easy to see that I created an overridden toString method to retu

21、rn the values of Rational, which will be very useful when I start exercising it from the RunRational driver code.</p><p>　　Notice the syntax around toString, however: the override keyword in the front of the

22、 definition is required so that Scala can check to make sure that a corresponding definition exists in the base class. This can help prevent subtle bugs created by accidental keyboard slips. (It was this same motivation

23、that led to the creation of the @Override annotation in Java 5.) Notice, as well, that the return type is not specified -- it's obvious from the definition of the method body -- and that the retur</p><p>

24、;　　Some core values</p><p>　　Next up are the definitions of numer and denom, respectively. The syntax involved, offhand, would lead the Java programmer to believe that numer and denom are public Int fields t

25、hat are initialized to the value of n-over-g and d-over-g, respectively; but this assumption is incorrect.</p><p>　　Formally, Scala calls numer and denom methods without parameters, which are used to create

26、a quick-and-easy syntax for defining accessors. The Rational class still has three private fields, n, d, and g, but they are hidden from the world by default private access in the case of n and d, and by explicit private

27、 access in the case of g.</p><p>　　The Java programmer in you is probably asking at this point, "Where are the corresponding "setters" for n and d?" No such setters exist. Part of the pow

28、er of Scala is that it encourages developers to create immutable objects by default. Granted, syntax is available to create methods for modifying the internals of Rational, but doing so would ruin the implicit thread-saf

29、e nature of this class. As a result, at least for this example, I'm going to leave Rational as it is.</p><p>　　Naturally, that raises the question of how one manipulates a Rational. Like java.lang.String

30、s, you can't take an existing Rational and modify its values, so the only alternative is to create new Rationals out of the values of an existing one, or create it from scratch. This brings into focus the next set of

31、 four methods: the curiously named +, -, *, and / methods.</p><p>　　And no, contrary to what it might look like, this isn't operator-overloading.</p><p>　　Operator, ring me a number</p>

32、;<p>　　Remember that in Scala everything is an object. In the last article, you saw how that principle applies to the idea that functions themselves are objects, which allows Scala programmers to assign functions

33、to variables, pass functions as object parameters, and so on. An equally important principle is that everything is a function; that is to say, in this particular case, there is no distinction between a function named add

34、 and a function named +. In Scala, all operators are functions on a class.</p><p>　　In the Rational class, then, four operations have been defined for rational numbers. These are the canonical, mathematical

35、operations add, subtract, multiply, and divide. Each of these is named by its mathematical symbol: +, -, *, and /.</p><p>　　Notice, however, that each of these operators works by constructing a new Rational

36、object each time. Again, this is very similar to how java.lang.String works, and it is the default implementation because it yields thread-safe code. (If no shared state -- and internal state of an object shared across t

37、hreads is implicitly shared state -- is modified by a thread, then there is no concern over concurrent access to that state.)</p><p>　　What's new with you?</p><p>　　The everything is a funct

38、ion rule has two powerful effects:</p><p>　　The first, as you've already seen, is that functions can be manipulated and stored as objects themselves. This leads to powerful re-use scenarios like the one

39、explored in the first article in this series.</p><p>　　The second effect is that there is no special distinction between the operators that the Scala-language designers might think to provide and the operato

40、rs that Scala programmers think should be provided. For example, let's assume for a moment that it makes sense to provide an "inversion" operator, which will flip the numerator and denominator and return a

41、new Rational (so that Rational(2,5) will return Rational(5,2)). If you decide that the ~ symbol best represents this concept, then you can def</p><p>　　Defining this unary "operator" in Scala is sl

42、ightly tricky, but it's purely a syntactic nit:Listing 6. This is how you flip</p><p>　　The tricky part is, of course, the fact that you have to prefix the ~ name with "unary_" to tell the Sca

43、la compiler that it is intended to be a unary operator; therefore, the syntax will be "flipped" from the traditional reference-then-method syntax common in most object languages.</p><p>　　Note that

44、 this combines with the "everything is an object" rule to create some powerful -- but easy-to-explain -- code opportunities:</p><p>　　Listing 7. Add it up</p><p>　　Naturally, the Scala

45、 compiler "does the right thing" for the straight integer addition examples, but syntactically it's all the same. This means that you can develop types that are no different from the "built-in" ty

46、pes that come as part of the Scala language.</p><p>　　The Scala compiler will even try to infer some meaning out of the "operators" that have some predetermined meaning, such as the += operator. No

47、te how the following code just does what it should, despite the fact that the Rational class doesn't have an explicit definition for +=:</p><p>　　Listing 8. Scala infers</p><p>　　When printe

48、d, r5 has the value [13 / 12], which is exactly what it should be.</p><p>　　Scala under the hood</p><p>　　Remember that Scala compiles to Java bytecode, meaning that it runs on the JVM. If you n

49、eed proof, look no further than the fact that the compiler is producing .class files that begin with 0xCAFEBABE, just like javac does. Also note what happens if you fire up the Java bytecode disassembler that comes with

50、the JDK (javap) and point it at the generated Rational class, as shown in Listing 9:Listing 9. Classes compiled from rational.scala</p><p>　　The "operators" defined in the Scala class transmogrify

51、 into method calls in the best tradition of Java programming, though they do seem to be based on funny names. Two constructors are defined on the class: one taking an int and one taking a pair of ints. And, if you happen

52、 to be at all concerned that the use of the upper-case Int type is somehow a java.lang.Integer in disguise, note that the Scala compiler is smart enough to transform them into regular Java primitive ints in the class def

53、initi</p><p>　　Testing, testing, 1-2-3...</p><p>　　It is a well-known meme that good programmers write code, and great programmers write tests; thus far, I have been lax in exercising this rule

54、for my Scala code, so let’s see what happens when you put this Rational class inside of a traditional JUnit test suite, as shown in Listing 10:</p><p>　　Listing 10. RationalTest.java</p><p>　　As

55、ide from confirming that the Rational class behaves, well, rationally, the above test suite also proves that it is possible to call Scala code from Java code (albeit with a little bit of an impedance mismatch when it com

56、es to the operators). The cool thing about this, of course, is that it lets you try out Scala slowly, by migrating Java classes over to Scala classes without ever having to change the tests that back them.</p><

57、;p>　　The only weirdness you might notice in the test code has to do with operator invocation, in this case, the + method on the Rational class. Looking back at the javap output, Scala has obviously translated the + fu

58、nction into the JVM method $plus, but the Java Language Specification does not allow the $ character in identifiers (which is why it's used in nested and anonymous nested class names).</p><p>　　In order

59、to invoke those methods, you either have to write the tests in Groovy or JRuby (or some other language that doesn't pose a restriction on the $ character), or you can write a little bit of Reflection code to invoke i

60、t. I go with the latter approach, which isn't all that interesting from a Scala perspective, but the result is included in this article's code bundle, should you be curious. (SeeDownload.)</p><p>　　N

61、ote that workarounds like these are only necessary for function names that aren't also legitimate Java identifiers.</p><p>　　A "better" Java</p><p>　　Back when I was first learning

62、 C++, Bjarne Stroustrup suggested that one way to learn C++ was to see it as "a better C" (see Resources). In some ways, Java developers today might come to see Scala as a "better Java," because it pr

63、ovides a more terse and succinct way of writing traditional Java POJOs. Consider the traditional Person POJO shown in Listing 11:</p><p>　　Listing 11. JavaPerson.java (original POJO)</p><p>　　No

64、w consider its equivalent written in Scala:</p><p>　　Listing 12. person.scala (threadsafe POJO)</p><p>　　It isn't a complete drop-in replacement, given that the original Person had some muta

65、ble setters. But considering the original Person also had no synchronization code around those mutable setters, the Scala version is safer to use. Also, if the goal is to truly reduce the number of lines of code in Perso

66、n, you could remove the getFoo property methods entirely because Scala will generate accessor methods around each of the constructor parameters -- firstName() returns a String, lastName() returns</p><p>　　Ev

67、en if the need for those mutable setter methods is undeniable, the Scala version is still simpler, as you can see in Listing 13:</p><p>　　Listing 13. person.scala (full POJO)</p><p>　　As an asid

68、e, notice the introduction of the var keyword on the constructor parameters. Without going into too much detail, var tells the compiler that the value is mutable. As a result, Scala generates both accessor (String firstN

69、ame(void)) and mutator (void firstName_$eq(String)) methods. It then becomes easy to create setFoo property mutator methods that use the generated mutator methods under the hood.</p><p>　　Conclusion</p>

70、;<p>　　Scala is an attempt to incorporate functional concepts and terseness without losing the richness of the object paradigm. As you've perhaps begun to see in this series, Scala also corrects some of the eg

71、regious (in hindsight) syntactic problems found in the Java language.</p><p>　　This second article in the Busy Java developer's guide to Scala series has focused on Scala's object facilities, which l

72、et you start using Scala without having to dive too deeply into the functional pool. Based on what you've learned so far, you can already start using Scala to reduce your programming workload. Among other things, you

73、 can use Scala to produce the very same POJOs needed for other programming environments, such as Spring or Hibernate.</p><p>　　Hold on to your diving caps and scuba gear, however, because next month's ar

74、ticle will mark the beginning of our descent into the deep end of the functional pool.</p><p><b>　　外文翻譯</b></p><p>　　面向Java開發(fā)人員的Scala指南:類操作</p><p>　　Java? 開發(fā)人員可以將對象作為理解S

75、cala的出發(fā)點。本文是面向Java開發(fā)人員的 Scala指南系列的第二期，作者Ted Neward遵循對一種語言進行評價的基本前提：一種語言的威力可以直接通過它集成新功能的能力衡量，在本文中就是指對復(fù)數(shù)的支持。跟隨本文，您將了解在Scala中與類的定義和使用有關(guān)的一些有趣特性。</p><p>　　在上一期文章中，您只是稍微了解了一些 Scala 語法，這些是運行 Scala 程序和了解其簡單特性的最基本要求。

76、通過上一篇文章中的Hello World 和 Timer 示例程序，您了解了Scala的Application類、方法定義和匿名函數(shù)的語法，還稍微了解Array[] 和一些類型推斷方面的知識。Scala 還提供了很多其他特性，本文將研究 Scala 編程中的一些較復(fù)雜方面。</p><p>　　Scala的函數(shù)編程特性非常引人注目，但這并非Java開發(fā)人員應(yīng)該對這門語言感興趣的惟一原因。實際上，Scala 融合了

77、函數(shù)概念和面向?qū)ο蟾拍睢榱俗孞ava和Scala程序員感到得心應(yīng)手，可以了解一下Scala 的對象特性，看看它們是如何在語言方面與 Java對應(yīng)的。記住，其中的一些特性并不是直接對應(yīng)，或者說，在某些情況下，“對應(yīng)” 更像是一種類比，而不是直接的對應(yīng)。不過，遇到重要區(qū)別時，我會指出來。</p><p>　　Scala和Java一樣使用類</p><p>　　我們不對Scala支持的類特性作

78、冗長而抽象的討論，而是著眼于一個類的定義，這個類可用于為Scala平臺引入對有理數(shù)的支持（主要借鑒自“Scala By Example”，參見參考資料）：清單 1. rational.scala</p><p>　　從詞匯上看，清單1的整體結(jié)構(gòu)與Java代碼類似，但是，這里顯然還有一些新的元素。在詳細(xì)討論這個定義之前，先看一段使用這個新 Rational 類的代碼：清單 2. RunRational</

79、p><p>　　清單 2 中的內(nèi)容平淡無奇：先創(chuàng)建兩個有理數(shù)，然后再創(chuàng)建兩個Rational，作為前面兩個有理數(shù)的和與差，最后將這幾個數(shù)回傳到控制臺上（注意，Console.println()來自Scala核心庫，位于scala.* 中，它被隱式地導(dǎo)入每個Scala程序中，就像Java編程中的java.lang一樣）。</p><p>　　用多少種方法構(gòu)造類？</p><p

80、>　　現(xiàn)在，回顧一下Rational類定義中的第一行：清單 3.Scala的默認(rèn)構(gòu)造函數(shù)</p><p>　　您也許會認(rèn)為清單 3 中使用了某種類似于泛型的語法，這其實是Rational類的默認(rèn)的、首選的構(gòu)造函數(shù)：n和d是構(gòu)造函數(shù)的參數(shù)。</p><p>　　Scala優(yōu)先使用單個構(gòu)造函數(shù)，這具有一定的意義——大多數(shù)類只有一個構(gòu)造函數(shù)，或者通過一個構(gòu)造函數(shù)將一組構(gòu)造函數(shù)“鏈接”起來

81、。如果需要，可以在一個Rational上定義更多的構(gòu)造函數(shù)，例如：清單 4. 構(gòu)造函數(shù)鏈</p><p>　　注意，Scala的構(gòu)造函數(shù)鏈通過調(diào)用首選構(gòu)造函數(shù)（Int,Int版本）實現(xiàn)Java構(gòu)造函數(shù)鏈的功能。</p><p><b>　　實現(xiàn)細(xì)節(jié)</b></p><p>　　在處理有理數(shù)時，采取一點數(shù)值技巧將會有所幫助：也就是說，找到公分母

82、，使某些操作變得更容易。如果要將1/2與2/4相加，那 Rational類應(yīng)該足夠聰明，能夠認(rèn)識到2/4和1/2是相等的，并在將這兩個數(shù)相加之前進行相應(yīng)的轉(zhuǎn)換。嵌套的私有g(shù)cd()函數(shù)和 Rational 類中的g值可以實現(xiàn)這樣的功能。在Scala中調(diào)用構(gòu)造函數(shù)時，將對整個類進行計算，這意味著將g初始化為n和d的最大公分母，然后用它依次設(shè)置n和d。</p><p>　　回顧一下清單1就會發(fā)現(xiàn)，我創(chuàng)建了一個覆蓋的t

83、oString方法來返回Rational的值，在RunRational驅(qū)動程序代碼中使用toString時，這樣做非常有用。</p><p>　　然而，請注意toString的語法：定義前面的override關(guān)鍵字是必需的，這樣Scala才能確認(rèn)基類中存在相應(yīng)的定義。這有助于預(yù)防因意外的輸入錯誤導(dǎo)致難于覺察的 bug（Java 5中創(chuàng)建@Override注釋的動機也在于此）。還應(yīng)注意，這里沒有指定返回類型 ——

84、從方法體的定義很容易看出——返回值沒有用return關(guān)鍵字顯式地標(biāo)注，而在Java中則必須這樣做。相反，函數(shù)中的最后一個值將被隱式地當(dāng)作返回值（但是，如果您更喜歡Java語法，也可以使用return關(guān)鍵字）。</p><p><b>　　一些重要值</b></p><p>　　接下來分別是numer和denom的定義。這里涉及的語法可能讓Java程序員認(rèn)為numer和

85、denom是公共的Int字段，它們分別被初始化為n-over-g和d-over-g；但這種想法是不對的。</p><p>　　在形式上，Scala調(diào)用無參數(shù)的numer和denom方法，這種方法用于創(chuàng)建快捷的語法以定義accessor。Rational類仍然有3個私有字段：n、d和g，但是，其中的n和d被默認(rèn)定義為私有訪問，而g則被顯式地定義為私有訪問，它們對于外部都是隱藏的。</p><p&

86、gt;　　此時，Java 程序員可能會問：“n和d各自的‘setter’在哪里？”Scala中不存在這樣的 setter。Scala的一個強大之處就在于，它鼓勵開發(fā)人員以默認(rèn)方式創(chuàng)建不可改變的對象。但是，也可使用語法創(chuàng)建修改Rational內(nèi)部結(jié)構(gòu)的方法，但是這樣做會破壞該類固有的線程安全性。因此，至少對于這個例子而言，我將保持Rational不變。</p><p>　　當(dāng)然還有一個問題，如何操縱Rational

87、呢？與java.lang.String一樣，不能直接修改現(xiàn)有的Rational的值，所以惟一的辦法是根據(jù)現(xiàn)有類的值創(chuàng)建一個新的Rational，或者從頭創(chuàng)建。這涉及到4個名稱比較古怪的方法：+、 -、* 和 /。</p><p>　　與其外表相反，這并非操作符重載。</p><p><b>　　操作符</b></p><p>　　記住，在Sca

88、la中一切都是對象。在上一篇文章中，您看到了函數(shù)本身也是對象這一原則的應(yīng)用，這使Scala程序員可以將函數(shù)賦予變量，將函數(shù)作為對象參數(shù)傳遞等等。另一個同樣重要的原則是，一切都是函數(shù)；也就是說，在此處，命名為add的函數(shù)與命名為 + 的函數(shù)沒有區(qū)別。在Scala中，所有操作符都是類的函數(shù)。只不過它們的名稱比較古怪罷了。</p><p>　　在Rational類中，為有理數(shù)定義了4種操作。它們是規(guī)范的數(shù)學(xué)操作：加、減

89、、乘、除。每種操作以它的數(shù)學(xué)符號命名：+、-、 * 和 /。</p><p>　　但是請注意，這些操作符每次操作時都構(gòu)造一個新的Rational對象。同樣，這與java.lang.String非常相似，這是默認(rèn)的實現(xiàn)，因為這樣可以產(chǎn)生線程安全的代碼（如果線程沒有修改共享狀態(tài) —— 默認(rèn)情況下，跨線程共享的對象的內(nèi)部狀態(tài)也屬于共享狀態(tài) —— 則不會影響對那個狀態(tài)的并發(fā)訪問）。</p><p>

90、;<b>　　有什么變化？</b></p><p>　　一切都是函數(shù)，這一規(guī)則產(chǎn)生兩個重要影響：</p><p>　　首先，您已經(jīng)看到，函數(shù)可以作為對象進行操縱和存儲。這使函數(shù)具有強大的可重用性，本系列第一篇文章對此作了探討。</p><p>　　第二個影響是，Scala語言設(shè)計者提供的操作符與Scala程序員認(rèn)為應(yīng)該提供的操作符之間沒有特別的

91、差異。例如，假設(shè)提供一個“求倒數(shù)”操作符，這個操作符會將分子和分母調(diào)換，返回一個新的Rational（即對于Rational(2,5)將返回Rational（5，2））。如果您認(rèn)為~符號最適合表示這個概念，那么可以使用此符號作為名稱定義一個新方法，該方法將和Java代碼中任何其他操作符一樣，如清單5所示：</p><p><b>　　清單 5. 求倒數(shù)</b></p><

92、p>　　在 Scala 中定義這種一元操作符”需要一點技巧，但這只是語法上的問題而已：清單 6. 如何求倒數(shù)</p><p>　　當(dāng)然，需要注意的地方是，必須在名稱~之前加上前綴“unary_”，告訴Scala編譯器它屬于一元操作符。因此，該語法將顛覆大多數(shù)對象語言中常見的傳統(tǒng)reference- then-method語法。</p><p>　　這條規(guī)則與 “一切都是對象” 規(guī)

93、則結(jié)合起來，可以實現(xiàn)功能強大（但很簡單）的代碼：清單 7. 求和</p><p>　　當(dāng)然，對于簡單的整數(shù)加法，Scala編譯器也會“得到正確的結(jié)果”，它們在語法上是完全一樣的。這意味著您可以開發(fā)與Scala語言“內(nèi)置”的類型完全相同的類型。</p><p>　　Scala編譯器甚至?xí)L試推斷具有某種預(yù)定含義的“操作符”的其他含義，例如+= 操作符。注意，雖然Rational類并沒有顯式

94、地定義+=，下面的代碼仍然會正常運行：清單 8. Scala 推斷</p><p>　　打印結(jié)果時，r5的值為[13 / 12]，結(jié)果是正確的。</p><p><b>　　Scala 內(nèi)幕</b></p><p>　　記住，Scala將被編譯為Java字節(jié)碼，這意味著它在JVM上運行。如果您需要證據(jù)，那么只需注意編譯器生成以0xCAFEBA

95、BE開頭的.class文件，就像javac一樣。另外請注意，如果啟動JDK自帶的Java字節(jié)碼反編譯器（javap），并將它指向生成的Rational類，將會出現(xiàn)什么情況，如清單9所示：清單 9. 從 rational.scala 編譯的類</p><p>　　Scala類中定義的“操作符”被轉(zhuǎn)換成傳統(tǒng)Java編程中的方法調(diào)用，不過它們?nèi)允褂每瓷先ビ行┕殴值拿Q。類中定義了兩個構(gòu)造函數(shù)：一個構(gòu)造函數(shù)帶有一個in

96、t參數(shù)，另一個帶有兩個int參數(shù)。您可能會注意到，大寫的Int類型與java.lang.Integer有點相似，Scala編譯器非常聰明，會在類定義中將它們轉(zhuǎn)換成常規(guī)的Java原語int。</p><p>　　測試 Rational 類</p><p>　　一種著名的觀點認(rèn)為，優(yōu)秀的程序員編寫代碼，偉大的程序員編寫測試；到目前為止，我還沒有對我的Scala代碼嚴(yán)格地實踐這一規(guī)則，那么現(xiàn)在看

97、看將這個Rational類放入一個傳統(tǒng)的JUnit測試套件中會怎樣，如清單10所示：清單 10. RationalTest.java</p><p>　　除了確認(rèn)Rational類運行正常之外，上面的測試套件還證明可以從Java代碼中調(diào)用 Scala代碼（盡管在操作符方面有點不匹配）。當(dāng)然，令人高興的是，您可以將Java類遷移至Scala類，同時不必更改支持這些類的測試，然后慢慢嘗試Scala。</p&g

98、t;<p>　　您惟一可能覺得古怪的地方是操作符調(diào)用，在本例中就是Rational類中的 + 方法?；仡櫼幌耲avap的輸出，Scala顯然已經(jīng)將+函數(shù)轉(zhuǎn)換為JVM方法$plus，但是Java語言規(guī)范并不允許標(biāo)識符中出現(xiàn)$字符（這正是它被用于嵌套和匿名嵌套類名稱中的原因）。</p><p>　　為了調(diào)用那些方法，需要用Groovy或JRuby（或者其他對$字符沒有限制的語言）編寫測試，或者編寫Ref

99、lection代碼來調(diào)用它。我采用后一種方法，從Scala的角度看這不是那么有趣，但是如果您有興趣的話，可以看看本文的代碼中包含的結(jié)果（參見下載）。</p><p>　　注意，只有當(dāng)函數(shù)名稱不是合法的Java標(biāo)識符時才需要用這類方法。</p><p>　　“更好的” Java</p><p>　　我學(xué)習(xí)C++的時候Bjarne Stroustrup建議，學(xué)習(xí)C++的

100、一種方法是將它看作“更好的C語言”（參見 參考資料）。在某些方面，如今的Java開發(fā)人員也可以將Scala看作是“更好的Java”，因為它提供了一種編寫傳統(tǒng)Java POJO的更簡潔的方式?？紤]清單11中顯示的傳統(tǒng) Person POJO：清單 11. JavaPerson.java（原始 POJO）</p><p>　　現(xiàn)在考慮用 Scala 編寫的對等物：清單 12. person.scala（線程安全的

101、 POJO）</p><p>　　這不是一個完全匹配的替換，因為原始的Person包含一些可變的setter。但是，由于原始的Person沒有與這些可變setter相關(guān)的同步代碼，所以Scala版本使用起來更安全。而且，如果目標(biāo)是減少Person中的代碼行數(shù)，那么可以刪除整個getFoo屬性方法，因為Scala將為每個構(gòu)造函數(shù)參數(shù)生成accessor方法—— firstName()返回一個String，lastN

102、ame()返回一個String，age()返回一個int。</p><p>　　即使必須包含這些可變的setter方法，Scala版本仍然更加簡單，如清單13所示：清單 13. person.scala（完整的 POJO）</p><p>　　注意，構(gòu)造函數(shù)參數(shù)引入了var關(guān)鍵字。簡單來說，var告訴編譯器這個值是可變的。因此，Scala 同時生成 accessor（String fir