The scripting landscape has changed dramatically. Perl has added support for object orientation, Python has extended its object-oriented support, and more recently Ruby has made a name for itself as a full-fledged dynamic object-oriented scripting language with significant productivity benefits when compared to Java and C++.
Groovy follows the lead of Ruby by offering these dynamic object orientation features. Not only does it enhance Java by making it scriptable, but it also provides new OO features. You have already seen that Groovy provides reference types in cases where Java uses non-object primitive types, introduces ranges and closures as first-class objects, and has many shorthand notations for working with collections of objects. But these enhancements are just scratching the surface. If this were all that Groovy had to offer, it would be little more than syntactic sugar over normal Java. What makes Groovy stand apart is its set of dynamic features.
Class definition in Groovy is almost identical to Java; classes are declared using the class keyword and may contain fields, constructors, initializers, and methods. Methods and constructors may themselves use local variables as part of their implementation code. Scripts are different—offering additional flexibility but with some restrictions too. They may contain code, variable definitions, and method definitions as well as class definitions. We will describe how all of these members are declared and cover a previously unseen operator on the way.
Defining fields and local variables:
In its simplest terms, a variable is a name associated with a slot of memory that can hold a value. Just as in Java, Groovy has local variables, which are scoped within the method they are part of, and fields, which are associated with classes or instances of those classes. Fields and local variables are declared in much the same way, so we cover them together.
Declaring variables
Fields and local variables must be declared before first use (except for a special case involving scripts, which we discuss later). This helps to enforce scoping rules and protects the programmer from accidental misspellings. The declaration always involves specifying a name, and may optionally include a type, modifiers, and assignment of an initial value. Once declared, variables are referenced by their name.
Scripts allow the use of undeclared variables, in which case these variables are assumed to come from the script’s binding and are added to the binding if not yet there. The binding is a data store that enables transfer of variables to and from the caller of a script. Section 11.3.2 has more details about this mechanism.
Groovy uses Java’s modifiers—the keywords private , protected , and public for modifying visibility; 2 final for disallowing reassignment; and static to denote class variables. A nonstatic field is also known as an instance variable. These modifiers all have the same meaning as in Java.
The default visibility for fields has a special meaning in Groovy. When no visibility modifier is attached to field declaration, a property is generated for the respective name. You will learn more about properties in section 7.4 when we present GroovyBeans.
Defining the type of a variable is optional. However, the identifier must not stand alone in the declaration. When no type and no modifier are given, the def keyword must be used as a replacement, effectively indicating that the field or variable is untyped (although under the covers it will be declared as type Object). Listing 7.1 depicts the general appearance of field and variable declarations with optional assignment and using a comma-separated list of identifiers to declare multiple references at once.
- Listing 7.1 Variable declaration examples
- class SomeClass {
- public fieldWithModifier
- String typedField
- def untypedField
- protected field1, field2, field3
- private assignedField = new Date()
- static ClassField
- public static final String CONSTA = 'a', CONSTB = 'b'
- def someMethod(){
- def localUntypedMethodVar = 1
- int localTypedMethodVar = 1
- def localVarWithoutAssignment, andAnotherOne
- }
- }
- def localvar = 1
- boundvar1 = 1
- def someMethod(){
- localMethodVar = 1
- boundvar2 = 1
- }
- Listing 7.2 Variable declaration examples
- class Test{
- final static String PI = 3.14
- static void main(args)
- {
- assert PI.class.name == 'java.lang.String'
- assert PI.length() == 4
- new GroovyTestCase().shouldFail(ClassCastException.class){
- Float areaOfCircleRadiousOne = PI // Cannot assign String to typed variable as Float
- }
- }
- }
Referencing and dereferencing fields
In addition to referring to fields by name with the obj.fieldName syntax, they can also be referenced with the subscript operator, as shown in listing 7.3. This allows you to access fields using a dynamically determined name.
- Listing 7.3 Referencing fields with the subscript operator
- class Counter {
- public count = 0
- }
- def counter = new Counter()
- counter.count = 1
- assert counter.count == 1
- def fieldName = 'count'
- counter[fieldName] = 2
- assert counter['count'] == 2
- assert counter.count == 2
Listing 7.4 shows how to do that. To extend both set and get access, provide the methods
- Object get (String name)
- void set (String name, Object value)
- Listing 7.4 Extending the general field-access mechanism
- class PretendFieldCounter {
- public count = 0
- @Override
- Object get (String name) {
- return 'pretend value'
- }
- @Override
- void set (String name, Object value) {
- count++
- }
- }
- def pretender = new PretendFieldCounter()
- assert pretender.isNoField == 'pretend value'
- assert pretender.count == 0 // Field 'count' exist, so get method won't be called!
- pretender.isNoFieldEither = 'just to increase counter'
- assert pretender.count == 1
FOR THE GEEKS:
Referencing fields is also connected to the topic of properties, which we will explore in section 7.4, where we will discuss the need for the additional obj.@fieldNamesyntax.
Methods and parameters
Method declarations follow the same concepts you have seen for variables: The usual Java modifiers can be used; declaring a return type is optional; and, if no modifiers or return type are supplied, the def keyword fills the hole. When the def keyword is used, the return type is deemed to be untyped (although it can still have no return type, the equivalent of a void method). In this case, under the covers, the return type will be java.lang.Object . The default visibility of methods is public.
Listing 7.5 shows the typical cases in a self-describing manner.
- Listing 7.5 Declaring methods
- class TestClass {
- static void main(args) {
- def some = new TestClass()
- some.publicVoidMethod()
- assert 'hi' == some.publicUntypedMethod()
- assert 'ho' == some.publicTypedMethod()
- combinedMethod() // Call static method of current class
- }
- void publicVoidMethod(){}
- def publicUntypedMethod(){return 'hi'}
- String publicTypedMethod(){return 'ho'}
- protected static final void combinedMethod(){}
- }
NOTE.
The main(args) example illustrates that declaring explicit parameter types is optional. When type declarations are omitted, Object is used. Multiple parameters can be used in sequence, delimited by commas. Listing 7.6 shows that explicit and omitted parameter types can also be mixed.
- Listing 7.6 Declaring parameter lists
- class TestClass2 {
- static void main (args){
- assert 'untyped' == method(1)
- assert 'typed' == method('whatever')
- assert 'two args'== method(1,2)
- }
- static method(arg) {return 'untyped'}
- static method(String arg){return 'typed'}
- static method(arg1, Number arg2){return 'two args'}
- }
Note.
Listing 7.7 illustrates Groovy method definitions and calls supporting positional and named parameters, parameter lists of variable length, and optional parameters with default values. The example provides four alternative summing mechanisms, each highlighting different approaches for defining the method call parameters.
- Listing 7.7 Advanced parameter usages
- class Summer {
- // 1) Explicit arguments and a default value
- def sumWithDefaults(a, b, c=0){
- return a + b + c
- }
- // 2) Define arguments as a list
- def sumWithList(List args){
- return args.inject(0){sum,i -> sum += i}
- }
- // 3) Optional arguments as an array
- def sumWithOptionals(a, b, Object[] optionals){
- return a + b + sumWithList(optionals.toList())
- }
- // 4) Define arguments as a map
- def sumNamed(Map args){
- ['a','b','c'].each{args.get(it,0)}
- return args.a + args.b + args.c
- }
- }
- def summer = new Summer()
- assert 2 == summer.sumWithDefaults(1,1)
- assert 3 == summer.sumWithDefaults(1,1,1)
- assert 2 == summer.sumWithList([1,1])
- assert 3 == summer.sumWithList([1,1,1])
- assert 2 == summer.sumWithOptionals(1,1)
- assert 3 == summer.sumWithOptionals(1,1,1)
- assert 2 == summer.sumNamed(a:1, b:1)
- assert 3 == summer.sumNamed(a:1, b:1, c:1)
- assert 1 == summer.sumNamed(c:1)
Using lists as shown in (2) is easy in Groovy, because in the method call, the arguments only have to be placed in brackets. We can also support argument lists of arbitrary length. However, it is not as obvious what the individual list entries should mean. Therefore, this alternative is best suited when all arguments have the same meaning, as they do here where they are used for adding. Regarding the inject method, it will iterates through the given Collection, passing in the initial value to the 2-arg closure along with the first item.
The sumWithOptionals method at (3) can be called with two or more parameters. To declare such a method, define the last argument as an array. Groovy’s dynamic method dispatch bundles excessive arguments into that array.
Named arguments can be supported by using a map as in (4). It is good practice to reset any missing values to a default before working with them. This also better reveals what keys will be used in the method body, because this is not obvious from the method declaration.
When designing your methods, you have to choose one of the alternatives. You may wish to formalize your choice within a project or incorporate the Groovy coding style.
Note.
Advanced naming
When calling a method on an object reference, we usually follow this format:
This format imposes the Java restrictions for method names; for example, they may not contain special characters such as minus ( - ) or dot ( . ). However, Groovy
allows you to use these characters in method names if you put quotes around the name:
The purpose of this feature is to support usages where the method name of a call becomes part of the functionality. You won’t normally use this feature directly, but it will be used under the covers by other parts of Groovy. You will see this in action in chapter 8 and chapter 10.
FOR THE GEEKS.
Where there’s a string, you can generally also use a GString. So how about obj."${var}"() ? Yes, this is also possible, and the GString will be resolved to determine the name of the method that is called on the object!
Safe dereferencing with the ?. operator:
When a reference doesn’t point to any specific object, its value is null . When calling a method or accessing a field on a null reference, a NullPointerException (NPE) is thrown. This is useful to protect code from working on undefined preconditions, but it can easily get in the way of “best effort” code that should be executed for valid references and just be silent otherwise.
Listing 7.8 shows several alternative approaches to protect code from NPEs. As an example, we wish to access a deeply nested entry within a hierarchy of maps, which results in a path expression—a dotted concatenation of references that is typically cumbersome to protect from NPEs. We can use explicit if checks or use the try-catch mechanism. Groovy provides the additional ?. operator for safe dereferencing. When the reference before that operator is a null reference, the evaluation of the current expression stops, and null is returned.
- Listing 7.8 Protecting from NullPointerExceptions using the ?. operator
- def map = [a:[b:[c:1]]]
- assert map.a.b.c == 1
- // 1) Protect with if: short-circuit evaluation
- if (map && map.a && map.a.x){
- assert map.a.x.c == null
- }
- // 2) Protect with try/catch
- try {
- assert map.a.x.c == null
- } catch (NullPointerException npe){npe.printStackTrace()}
- // 3) Safe dereferencing
- assert map?.a?.x?.c == null
Constructors:
Objects are instantiated from their classes via constructors. If no constructor is given, an implicit constructor without arguments is supplied by the compiler. This appears to be exactly like in Java, but because this is Groovy, it should not be surprising that some additional features are available.
Previously, we examined the merits of named parameters versus positional ones, as well as the need for optional parameters. The same arguments applicable to method calls are relevant for constructors, too, so Groovy provides the same convenience mechanisms. We’ll first look at constructors with positional parameters, and then we’ll examine named parameters.
Positional parameters
Until now, we have only used implicit constructors. Listing 7.9 introduces the first explicit one. Notice that just like all other methods, the constructor is public by default. We can call the constructor in three different ways: the usual Java way, with enforced type coercion by using the as keyword, and with implicit type coercion.
- Listing 7.9 Calling constructors with positional parameters
- class VendorWithCtor {
- String name, product
- // Constructor definition
- VendorWithCtor(name, product) {
- this.name = name
- this.product = product
- }
- }
- // Normal constructor use
- def first = new VendorWithCtor('Canoo','ULC')
- // 1) Coercion with as
- def second = ['Canoo','ULC'] as VendorWithCtor
- // 2) Coercion in assignment
- VendorWithCtor third = ['Canoo','ULC']
Named parameters
Named parameters in constructors are handy. One use case that crops up frequently is creating immutable classes that have some parameters that are optional. Using positional parameters would quickly become cumbersome because you would need to have constructors allowing for all combinations of the optional parameters.
As an example, suppose in listing 7.9 that VendorWithCtor should be immutable and name and product can be optional. We would need four constructors: an empty one, one to set name , one to set product , and one to set both attributes. To make things worse, we couldn’t have a constructor with only one argument, because we couldn’t distinguish whether to set the name or the product attribute (they are both strings). We would need an artificial extra argument for distinction, or we would need to strongly type the parameters.
But don’t panic: Groovy’s special way of supporting named parameters comes to the rescue again. Listing 7.10 shows how to use named parameters with a simplified version of the Vendor class. It relies on the implicit default constructor. Could that be any easier?
- Listing 7.10 Calling constructors with named parameters
- class Vendor {
- String name, product
- }
- new Vendor()
- new Vendor(name: 'Canoo')
- new Vendor(product:'ULC')
- new Vendor(name: 'Canoo', product:'ULC')
- def vendor = new Vendor(name: 'Canoo')
- assert 'Canoo' == vendor.name
Coming back to how we started this section, the empty default constructor call new Vendor() appears in a new light. Although it looks exactly like its Java equivalent, it is a special case of the default constructor with named parameters that happens to be called without any being supplied. (只要有空 constructor 存在, 就可以使用 named parameters constructor!)
Implicit constructors
Finally, there is a way to call a constructor implicitly by simply providing the constructor arguments as a list. That means that instead of calling the Dimension(width, height) constructor explicitly, for example, you can use:
- java.awt.Dimension area
- area = [200, 100]
- assert area.width == 200
- assert area.height == 100
Implicit constructors are often used with builders, as you’ll see in the SwingBuilder example in section 8.5.7.
That’s it for the usual class members. This is a solid basis we can build upon. But we are not yet in the penthouse; we have four more levels to go. We walk through the topic of how to organize classes and scripts to reach the level of advanced object-oriented features. The next floor is named GroovyBeans and deals with simple object-oriented information about objects. At this level, we can play with Groovy’s power features. Finally, we will visit the highest level, which is meta programming in Groovy—making the environment fully dynamic, and responding to ordinary-looking method calls and field references in an extraordinary way.
Supplement:
* Documentation > User Guide > Operators
* GUI Programming with Groovy > SwingBuilder
This message was edited 69 times. Last update was at 20/02/2014 22:37:24
沒有留言:
張貼留言