In imperative languages, expressions are usually evaluated as soon as they are declared.
This is not the case for functional languages like Scala, where it is possible to postpone the evaluation of an expression or to evaluate it multiple times.
In this fourth part of this series about functional programming we are going to talk about evaluation strategies in Scala and, specifically, about lazy vals and call by value.

After having introduced some of the core concepts of functional programming in the first part of this series and discussed partial functions and currying in the second, in this third part we are going to talk about another powerful feature of functional languages: Pattern matching.
Pattern matching can be thought of as an advanced version of switch in Java where, instead of just fixed values, a case can represent types, regular expressions and more.

In the last article we have introduced some of the core concepts of functional programming like higher-order functions, immutability and recursion.
Today we’ll continue talking about the functional side of Scala by covering partial functionsand currying.

Scala is an hybrid language in that it is object oriented and functional at the same time.
While most programmers are accustomed to OOP, the same cannot be said about functional programming.
This is the first of a series of articles about the fundamental concepts and techniques of this paradigm and their relative implementation in Scala.

Dependency Injection is a design pattern aiming at improving software quality by making classes easier to write, test and re-use.
One of the first libraries implementing this pattern was the Spring Framework, even though today there are many alternatives like Google Guice.
In this article we’ll see first what the advantages of DI are and then how Spring works and integrates with Play.

Mock objects are usually used in unit tests to replace the real objects used by the application.
In this article we are going to see when and how to use them. The library we are going to use is Mockito, which is one the most popular Java mocking framework. Mockito integrates very well with Spec2, the default testing library of Play.

In a many to many relation between two entities, each instance of one entity is linked to several instances of the other entity and vice versa.
In this article, we are going to implement this type of relationship using the Play Framework and we’ll cover all aspects involved, from data submission to the persistence in the database.
As a starting point, consider an application that implements CRUD operations for two entities: User and UserGroup. The relative source can be found on Github.

In a pure MVC approach, the View does not contain any logic and it only displays data coming from the Model.
In a more real-world scenario, the information to render in the view is not always directly available or properly formatted in the Model and it needs to be obtained with some additional processing.
A common strategy for these situations is to embed the required logic in the view itself.
However, this makes the resulting code very difficult to test, to refactor and to re-use outside of views.
For all of these reasons, it is better to move all the logic away from views and into Scala classes.
In this article we are going to do this using the Presenter pattern.

As the number of views in a web application grows, the quantity of parts common across multiple pages increases as well.
Apart from headers and footers, many views share the same structure and layout.
Including sub-views is a way to re-use common sections but this still requires lots of copy-paste, resulting in duplication and maintainability issues.
A much better approach is to create base layouts containing the common parts and to extend them with what is specific to a certain view.
We have already seen how to use a layout when we discussed Play View Templates, but in this article we are going to go deeper into the subject.

After having discussed data submission and validation in a past article, today we are going to go deeper into the subject and use some of the more advanced features that Play provides to work with forms like field constructors, custom form mapping and two-step validation.