In order to show the lens design pattern in practice, we will create a class hierarchy that is usually seen in enterprise applications. Let's imagine that we are building a system for a library that can be used by the employees of different companies. We might end up with the following classes:

case class Country(name: String, code: String)
case class City(name: String, country: Country)
case class Address(number: Int, street: String, city: City)
case class Company(name: String, address: Address)
case class User(name: String, company: Company, address: Address)

The representation of these classes as a class diagram would look like the following figure:

The diagram is pretty clear and it doesn't need too much explanation. We basically have a User class that has other information about the user. Other classes contain others and so on. There is absolutely no challenge in using our classes if we don't want to be able to modify anything. However, as soon as we go on to modify something, it becomes complicated.

In this subsection, we will see how to use our classes if we want to modify some of their properties.

Immutable and verbose

Without getting into too much details, let's see how an example application would look like:

object UserVerboseExample {
  def main(args: Array[String]): Unit = {
    val uk = Country("United Kingdom", "uk")
    val london = City("London", uk)
    val buckinghamPalace = Address(1, "Buckingham Palace Road", london)
    val castleBuilders = Company("Castle Builders", buckinghamPalace)
    
    val switzerland = Country("Switzerland", "CH")
    val geneva = City("geneva", switzerland)
    val genevaAddress = Address(1, "Geneva Lake", geneva)
    
    val ivan = User("Ivan", castleBuilders, genevaAddress)
    System.out.println(ivan)
    
    System.out.println("Capitalize UK code...")

    val ivanFixed = ivan.copy(
      company = ivan.company.copy(
        address = ivan.company.address.copy(
          city = ivan.company.address.city.copy(
            country = ivan.company.address.city.country.copy(
              code = ivan.company.address.city.country.code.toUpperCase
            )
          )
        )
      )
    )
    System.out.println(ivanFixed)
  }
}

The preceding application creates one user for our library and then decides to change the company country code, as we initially created it in lowercase characters. The output of the application looks like this:

Our application works correctly but as you can see in the highlighted code, it is extremely verbose and long and making a mistake is really easy. We don't want to write code like this, as it will be hard to maintain and change in the future.

case class Country(var name: String, var code: String)
case class City(var name: String, var country: Country)
case class Address(var number: Int, var street: String, var city: City)
case class Company(var name: String, var address: Address)
case class User(var name: String, var company: Company, var address: Address)

object UserBadExample {
  def main(args: Array[String]): Unit = {
    val uk = Country("United Kingdom", "uk")
    val london = City("London", uk)
    val buckinghamPalace = Address(1, "Buckingham Palace Road", london)

    val castleBuilders = Company("Castle Builders", buckinghamPalace)

    val switzerland = Country("Switzerland", "CH")
    val geneva = City("geneva", switzerland)
    val genevaAddress = Address(1, "Geneva Lake", geneva)

    val ivan = User("Ivan", castleBuilders, genevaAddress)
    System.out.println(ivan)

    System.out.println("Capitalize UK code...")

    ivan.company.address.city.country.code = ivan.company.address.city.country.code.toUpperCase
    System.out.println(ivan)
  }
}

In the previous subsection, we saw how complicated something such as changing one property of a nested class can be. We are going after nice, clean, and correct code, and we also don't want to go against the principles of Scala.

Luckily for us, cases such as the one we just mentioned previously are exactly the reason for the creation of the lens design pattern. In this chapter, we will see the Scalaz library for the first time in this book. It defines many functional programming abstractions for us, and we can use them straight away easily without worrying whether they follow some specific set of rules or not.

So what are lenses anyway? We won't get too deep into the theoretical aspects here, as this is out of the scope of this book. It is enough for us to know for what they are used for, and if you want to know more, there is plenty of material on lenses, store, and comonads online, which can make these concepts clearer. A simple way to represent a lens is the following:

case class Lens[X, Y](get: X => Y, set: (X, Y) => X)

This basically lets us get and set different properties of an object of the X type. This means that, in our case, we will have to define different lenses for the different properties we want to set:

object User {
  val userCompany = Lens.lensu[User, Company](
    (u, company) => u.copy(company = company),
    _.company
  )
  
  val userAddress = Lens.lensu[User, Address](
    (u, address) => u.copy(address = address),
    _.address
  )
  
  val companyAddress = Lens.lensu[Company, Address](
    (c, address) => c.copy(address = address),
    _.address
  )
  
  val addressCity = Lens.lensu[Address, City](
    (a, city) => a.copy(city = city),
    _.city
  )
  
  val cityCountry = Lens.lensu[City, Country](
    (c, country) => c.copy(country = country),
    _.country
  )
  
  val countryCode = Lens.lensu[Country, String](
    (c, code) => c.copy(code = code),
    _.code
  )
  
  val userCompanyCountryCode = userCompany >=> companyAddress >=> addressCity >=> cityCountry >=> countryCode
}

The preceding code is a companion object to our User class. There are a lot of things going on here, so we will explain this. You can see the calls to Lens.lensu[A, B]. They create actual lenses that for an object of the A type, the calls get and set a value of the B type. There is nothing special about them really, and they simply look like a boiler plate code. The interesting part here is the highlighted code—it uses the >=> operator, which is an alias for andThen. This allows us to compose lenses and this is exactly what we will do. We will define a composition that allows us to go from a User object through the chain and set the country code of the country of the Company. We could have used compose as well, which has an alias of <=< because andThen internally calls compose and it would look like the following:

val userCompanyCountryCodeCompose = countryCode <=< cityCountry <=< addressCity <=< companyAddress <=< userCompany

The latter, however, is not as intuitive as the former. Using our lens is now very easy. We need to make sure to import our companion object and then we can simply use the following code where we change the country code to upper case:

val ivanFixed = userCompanyCountryCode.mod(_.toUpperCase, ivan)

You saw how the lens design pattern allows us to cleanly set properties of our case class without breaking the immutability rule. We simply need to define the right lenses and then use them.