|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 5
The Spring framework at its core is a dependency injection container. It lets developers create loosely coupled components and then specify metadata, which it uses to construct and wire up an application's components. A die-hard Scala programmer would reject Spring's dependency injection model, however. In Scala, we do not inject instances of other objects but compose functionality. Scala replaces Spring's dependency injection with its own composition inheritance.
Rather than rewrite Spring-based Java applications in pure Scala, perhaps using Scala's Cake pattern (an alternative to dependency injection), you can start integrating Scala into your Java projects as test code. This approach will let you leverage the functional features of the Scala language and its testing frameworks without rewriting your main code. You will learn Scala while also keeping your Java programs relatively safe: safe from Scala beginner code. As you use Scala in your tests, you'll gradually discover the patterns of a Scala system. You'll learn over time where it's appropriate to apply Scala's patterns in your Java apps. Eventually, you'll begin to write new components in Scala, even in your main codebase.
We'll start out with a typical Spring-based Java application. Let's say we've created a domain class using JPA annotations,
then used Hibernate to persist the objects in an RDBMS. We've also used Hibernate in our service object. We have a domain with a Rider class and a RiderManager that depends on Hibernate's API. We've used the Spring framework to manage dependencies between all of the components that
make up the application. The application is implemented entirely in Java code.
Now we can implement a standard JUnit test with Scala. This is no problem because Scala compiles to Java bytecode. As far as the JVM is concerned, there is no difference between Scala and Java. Writing a JUnit test in Scala lets us benefit from Scala's concise syntax with inferred types; you can see this in Listing 1.
@RunWith(classOf[JUnit4])
class RiderManagerOldTest {
private var riderManager: RiderManager = _
private val hibernateTemplate: HibernateTemplate = Mockito.mock(classOf[HibernateTemplate])
@Before
def setup() {
this.riderManager = new RiderManager(this.hibernateTemplate)
}
@Test
def generate() {
this.riderManager.generate(2)
val allRiders = this.riderManager.findAll
Assert.assertThat(allRiders.size(), CoreMatchers.is(2))
}
}
The Scala code in Listing 1 matches exactly the Java code it has replaced; it's just a lot cleaner. I've removed all public keywords, replacing @Test-annotated methods returning void with def. The fields use the keyword var for a variable that can be bound-to more than once, and val for a variable that can be bound-to only once. Listing 1 gives you a glimpse of some of the benefits of Scala: no need for
semicolons at the end of every line and type inference of the allRiders variable. In Listing 2, I mechanically translate the Scala code back into Java.