Scala Design Patterns - Second Edition

4 (4 reviews total)
By Ivan Nikolov
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. The Design Patterns Out There and Setting Up Your Environment

About this book

Design patterns make developers’ lives easier by helping them write great software that is easy to maintain, runs efficiently, and is valuable to the company or people concerned. You’ll learn about the various features of Scala and will be able to apply well-known, industry-proven design patterns in your work.

The book starts off by focusing on some of the most interesting and latest features of Scala while using practical real-world examples.  We will be learning about IDE’s and Aspect Oriented Programming. We will be looking into different components in Scala. We will also cover the popular "Gang of Four" design patterns and show you how to incorporate functional patterns effectively. The book ends with a practical example that demonstrates how the presented material can be combined in real-life applications. You’ll learn the necessary concepts to build enterprise-grade applications.

By the end of this book, you’ll have enough knowledge and understanding to quickly assess problems and come up with elegant solutions.

Publication date:
April 2018
Publisher
Packt
Pages
396
ISBN
9781788471305

 

Chapter 1. The Design Patterns Out There and Setting Up Your Environment

In the world of computer programming, there are multiple ways to create a solution to a given problem. However, some might wonder whether there is a correct way of achieving a specific task. The answer is yes; there is always a right way, but in software development, there are usually multiple right ways to achieve a task. Some factors exist that guide the programmer to the right solution and, depending on them, people tend to get the expected result. These factors could define many things—the actual language being used, the algorithm, the type of executable produced, the output format, and the code structure. In this book, the language is already chosen for us—Scala. There are, however, a number of ways to use Scala, and we will be focusing on them—the design patterns.

In this chapter, we will explain what design patterns are and why they exist. We will go through the different types of design patterns that are out there. This book aims to provide useful examples to aid you in the learning process, and being able to run them easily is key. Hence, some points on how to set up a development environment properly will be given here. The top-level topics we will go through are as follows:

  • What is a design pattern and why do they exist?
  • The main types of design patterns and their features
  • Choosing the right design pattern
  • Setting up a development environment in real life

The last point doesn't have much to do with design patterns. However, it is always a good idea to build projects properly, as this makes it much easier to work in the future.

 

Design patterns


Before delving into the Scala design patterns, we have to explain what they actually are, why they exist, and why it is worth being familiar with them.

Software is a broad subject, and there are innumerable examples of things people can do with it. At first glance, most of these things are completely different—games, websites, mobile phone applications, and specialized systems for different industries. There are, however, many similarities in how software is built. Many times, people have to deal with similar issues, no matter the type of software they create. For example, computer games, as well as websites, might need to access a database. And throughout time, by experience, developers learn how structuring their code differs for the various tasks that they perform.

Note

The formal definition for design patterns A design pattern is a reusable solution to a recurring problem in software design. It is not a finished piece of code but a template that helps to solve a particular problem or family of problems.

Design patterns are best practices at which the software community has arrived over a period of time. They are supposed to help you write efficient, readable, testable, and easily extendable code. In some cases, they can be the result of a programming language not being expressive enough to elegantly achieve a goal. This means that more feature-rich languages might not even need a design pattern, while others still do. Scala is one of those rich languages, and in some cases, it makes the use of some design patterns obsolete or simpler. We will see how exactly it does that in this book.

The lack or existence of a certain functionality within a programming language also makes it able to implement additional design patterns that others cannot. The opposite is also valid—it might not be able to implement things that others can.

Scala and design patterns

Scala is a hybrid language that combines features from object-oriented and functional languages. This not only allows it to keep some of the well-known object-oriented design patterns relevant, but also provides various other ways of exploiting its features to write code that is clean, efficient, testable, and extendable all at the same time. The hybrid nature of the language also makes some of the traditional object-oriented design patterns obsolete, or possible, using other cleaner techniques.

The need for design patterns and their benefits

Writing code without the conscious use of a design pattern is something many software engineers do. In the end, however, they either end up using one without realizing it, or they end up with code that can be improved in some way. As we mentioned earlier, design patterns help to write efficient, readable, extendable, and testable code. All these features are really important to companies in the industry.

Even though in some cases it is preferable to quickly write a prototype and get it out, it is more usually the case that a piece of software is supposed to evolve. Maybe you will have experience of extending some badly written code, but regardless, it is a challenging task and takes a really long time, and sometimes it feels that rewriting it would be easier. Moreover, this makes introducing bugs into the system much more likely.

Code readability is also something that should be appreciated. Of course, one could use a design pattern and still have their code hard to read, but generally, design patterns help. Big systems are usually worked on by many people, and everyone should be able to understand what exactly is going on. Also, people who join a team are able to integrate much more easily and quickly if they are working on a well-written piece of software.

Testability is something that prevents developers from introducing bugs when writing or extending code. In some cases, code could be created so badly that it is not even testable. Design patterns are supposed to eliminate these problems as well.

While efficiency is often connected with algorithms, design patterns could also affect it. A simple example could be an object that takes a long time to instantiate, and instances are used in many places in an application, but could be made a singleton instead. You will see more concrete examples in the later chapters of this book.

 

Design pattern categories


The fact that software development is an extremely broad topic leads to a number of things that can be done with programming. Requirements can vary greatly between different industries and engineering teams. These facts have caused many different design patterns to be invented. This is further contributed to by the existence of various programming languages with different features and levels of expressiveness.

This book focuses on the design patterns from the point of view of Scala. As we mentioned previously, Scala is a hybrid language. This leads us to a few famous design patterns that are not needed anymore—one example is the null object design pattern, which can simply be replaced by Scala's Option. Other design patterns become possible using different approaches—the decorator design pattern can be implemented using stackable traits. Finally, some new design patterns become available that are applicable specifically to the Scala programming language—the cake design pattern, pimp my library, and so on. We will focus on all of these and make it clear where the richness of Scala helps us to make our code even cleaner and simpler.

Even if there are many different design patterns, they can all be grouped in the following:

  • Creational
  • Structural
  • Behavioral
  • Functional
  • Scala-specific design patterns

Some of the design patterns that are specific to Scala can be assigned to the previous groups. They can either be additions or replacements of the already existing ones. They are typical to Scala and take advantage of some advanced language features or simply features not available in other languages.

The first three groups contain the famous Gang of Four design patterns. Every design pattern book covers them and so will we. The rest, even if they can be assigned to one of the first three groups, will be specific to Scala and functional programming languages. In the next few subsections, we will explain the main characteristics of the listed groups and briefly present the actual design patterns that fall under them.

Creational design patterns

The creational design patterns deal with object creation mechanisms. Their purpose is to create objects in a way that is suitable to the current situation, which could lead to unnecessary complexity and the need for extra knowledge if they were not there. The main ideas behind the creational design patterns are as follows:

  • Knowledge encapsulation about the concrete classes
  • Hiding details about the actual creation and how objects are combined

We will be focusing on the following creational design patterns in this book:

  • The abstract factory design pattern
  • The factory method design pattern
  • The lazy initialization design pattern
  • The singleton design pattern
  • The object pool design pattern
  • The builder design pattern
  • The prototype design pattern

The following few sections give a brief definition of what these patterns are. They will be looked at in depth individually later in this book.

The abstract factory design pattern

This is used to encapsulate a group of individual factories that have a common theme. When used, the developer creates a specific implementation of the abstract factory and uses its methods in the same way as in the factory design pattern to create objects. It can be thought of as another layer of abstraction that helps to instantiate classes.

The factory method design pattern

This design pattern deals with the creation of objects without explicitly specifying the actual class that the instance will have—it could be something that is decided at runtime based on many factors. Some of these factors can include operating systems, different data types, or input parameters. It gives developers the peace of mind of just calling a method rather than invoking a concrete constructor.

The lazy initialization design pattern

This design pattern is an approach to delay the creation of an object or the evaluation of a value until the first time it is needed. It is much more simplified in Scala than it is in an object-oriented language such as Java.

The singleton design pattern

This design pattern restricts the creation of a specific class to just one object. If more than one class in the application tries to use such an instance, then this same instance is returned for everyone. This is another design pattern that can be easily achieved with the use of basic Scala features.

The object pool design pattern

This design pattern uses a pool of objects that are already instantiated and ready for use. Whenever someone requires an object from the pool, it is returned, and after the user is finished with it, it puts it back into the pool manually or automatically. A common use for pools are database connections, which generally are expensive to create; hence, they are created once and then served to the application on request.

The builder design pattern

The builder design pattern is extremely useful for objects with many possible constructor parameters that would otherwise require developers to create many overrides for the different scenarios an object could be created in. This is different to the factory design pattern, which aims to enable polymorphism. Many of the modern libraries today employ this design pattern. As we will see later, Scala can achieve this pattern really easily.

The prototype design pattern

This design pattern allows object creation using a clone() method from an already created instance. It can be used in cases when a specific resource is expensive to create or when the abstract factory pattern is not desired.

Structural design patterns

Structural design patterns exist in order to help establish the relationships between different entities in order to form larger structures. They define how each component should be structured so that it has very flexible interconnecting modules that can work together in a larger system. The main features of structural design patterns include the following:

  • The use of composition to combine the implementations of multiple objects
  • Help build a large system made of various components by maintaining a high level of flexibility

In this book, we will focus on the following structural design patterns:

  • The adapter design pattern
  • The decorator design pattern
  • The bridge design pattern
  • The composite design pattern
  • The facade design pattern
  • The flyweight design pattern
  • The proxy design pattern

The next subsections will put some light on what these patterns are about before we delve into them later in this book.

The adapter design pattern

The adapter design pattern allows the interface of an existing class to be used from another interface. Imagine that there is a client who expects your class to expose a doWork() method. You might have the implementation ready in another class, but the method is called differently and is incompatible. It might require extra parameters too. This could also be a library that the developer doesn't have access to for modifications. This is where the adapter can help by wrapping the functionality and exposing the required methods. The adapter is useful for integrating the existing components. In Scala, the adapter design pattern can be easily achieved using implicit classes.

The decorator design pattern

Decorators are a flexible alternative to sub classing. They allow developers to extend the functionality of an object without affecting other instances of the same class. This is achieved by wrapping an object of the extended class into one that extends the same class and overrides the methods whose functionality is supposed to be changed. Decorators in Scala can be built much more easily using another design pattern called stackable traits.

The bridge design pattern

The purpose of the bridge design pattern is to decouple an abstraction from its implementation so that the two can vary independently. It is useful when the class and its functionality vary a lot. The bridge reminds us of the adapter pattern, but the difference is that the adapter pattern is used when something is already there and you cannot change it, while the bridge design pattern is used when things are being built. It helps us to avoid ending up with multiple concrete classes that will be exposed to the client. You will get a clearer understanding when we delve deeper in the topic, but for now, let's imagine that we want to have a FileReader class that supports multiple different platforms. The bridge will help us end up with FileReader, which will use a different implementation, depending on the platform. In Scala, we can use self-types in order to implement a bridge design pattern.

The composite design pattern

The composite is a partitioning design pattern that represents a group of objects that are to be treated as only one object. It allows developers to treat individual objects and compositions uniformly and to build complex hierarchies without complicating the source code. An example of composite could be a tree structure where a node can contain other nodes, and so on.

The facade design pattern

The purpose of the facade design pattern is to hide the complexity of a system and its implementation details by providing the client with a simpler interface to use. This also helps to make the code more readable and to reduce the dependencies of the outside code. It works as a wrapper around the system that is being simplified and, of course, it can be used in conjunction with some of the other design patterns mentioned previously.

The flyweight design pattern

The flyweight design pattern provides an object that is used to minimize memory usage by sharing it throughout the application. This object should contain as much data as possible. A common example given is a word processor, where each character's graphical representation is shared with the other same characters. The local information then is only the position of the character, which is stored internally.

The proxy design pattern

The proxy design pattern allows developers to provide an interface to other objects by wrapping them. They can also provide additional functionality, for example, security or thread-safety. Proxies can be used together with the flyweight pattern, where the references to shared objects are wrapped inside proxy objects.

Behavioral design patterns

Behavioral design patterns increase communication flexibility between objects based on the specific ways they interact with each other. Here, creational patterns mostly describe a moment in time during creation, structural patterns describe a more or less static structure, and behavioral patterns describe a process or flow. They simplify this flow and make it more understandable.

The main features of behavioral design patterns are as follows:

  • What is being described is a process or flow
  • The flows are simplified and made understandable
  • They accomplish tasks that would be difficult or impossible to achieve with objects

In this book, we will focus our attention on the following behavioral design patterns:

  • The value object design pattern
  • The null object design pattern
  • The strategy design pattern
  • The command design pattern
  • The chain of responsibility design pattern
  • The interpreter design pattern
  • The iterator design pattern
  • The mediator design pattern
  • The memento design pattern
  • The observer design pattern
  • The state design pattern
  • The template method design pattern
  • The visitor design pattern

The following subsections will give brief definitions of the aforementioned behavioral design patterns.

The value object design pattern

Value objects are immutable and their equality is based not on their identity, but on their fields being equal. They can be used as data transfer objects, and they can represent dates, colors, money amounts, numbers, and more. Their immutability makes them really useful in multithreaded programming. The Scala programming language promotes immutability, and value objects are something that naturally occur there.

The null object design pattern

Null objects represent the absence of a value and they define a neutral behavior. This approach removes the need to check for null references and makes the code much more concise. Scala adds the concept of optional values, which can replace this pattern completely.

The strategy design pattern

The strategy design pattern allows algorithms to be selected at runtime. It defines a family of interchangeable encapsulated algorithms and exposes a common interface to the client. Which algorithm is chosen could depend on various factors that are determined while the application runs. In Scala, we can simply pass a function as a parameter to a method, and depending on the function, a different action will be performed.

The command design pattern

This design pattern represents an object that is used to store information about an action that needs to be triggered at a later time. The information includes the following:

  • The method name
  • The owner of the method
  • Parameter values

The client then decides which commands need to be executed and when by the invoker. This design pattern can easily be implemented in Scala using the by-name parameters feature of the language.

The chain of responsibility design pattern

The chain of responsibility is a design pattern where the sender of a request is decoupled from its receiver. This way, it makes it possible for multiple objects to handle the request and to keep logic nicely separated. The receivers form a chain where they pass the request and, if possible, they process it, and if not, they pass it to the next receiver. There are variations where a handler might dispatch the request to multiple other handlers at the same time. This somehow reminds us of function composition, which in Scala can be achieved using the stackable traits design pattern.

The interpreter design pattern

The interpreter design pattern is based on the ability to characterize a well-known domain with a language with a strict grammar. It defines classes for each grammar rule in order to interpret sentences in the given language. These classes are likely to represent hierarchies as grammar is usually hierarchical as well. Interpreters can be used in different parsers, for example, SQL or other languages.

The iterator design pattern

The iterator design pattern is when an iterator is used to traverse a container and access its elements. It helps to decouple containers from the algorithms performed on them. What an iterator should provide is sequential access to the elements of an aggregate object without exposing the internal representation of the iterated collection.

The mediator design pattern

This pattern encapsulates the communication between different classes in an application. Instead of interacting directly with each other, objects communicate through the mediator, which reduces the dependencies between them, lowers the coupling, and makes the overall application easier to read and maintain.

The memento design pattern

This pattern provides the ability to roll back an object to its previous state. It is implemented with three objects—originator, caretaker, and memento. The originator is the object with the internal state; the caretaker will modify the originator, and a memento is an object that contains the state that the originator returns. The originator knows how to handle a memento in order to restore its previous state.

The observer design pattern

This design pattern allows the creation of publish/subscribe systems. There is a special object called subject that automatically notifies all the observers when there are any changes in the state. This design pattern is popular in various GUI toolkits and generally where event handling is needed. It is also related to reactive programming, which is enabled by libraries such as Akka. We will see an example of this towards the end of this book.

The state design pattern

This design pattern is similar to the strategy design pattern, and it uses a state object to encapsulate different behavior for the same object. It improves the code's readability and maintainability by avoiding the use of large conditional statements.

The template method design pattern

This design pattern defines the skeleton of an algorithm in a method and then passes some of the actual steps to the subclasses. It allows developers to alter some of the steps of an algorithm without having to modify its structure. An example of this could be a method in an abstract class that calls other abstract methods, which will be defined in the children.

The visitor design pattern

The visitor design pattern represents an operation to be performed on the elements of an object structure. It allows developers to define a new operation without changing the original classes. Scala can minimize the verbosity of this pattern compared to the pure object-oriented way of implementing it by passing functions to methods.

Functional design patterns

We will be looking into all of the preceding design patterns from the point of view of Scala. This means that they will look different than in other languages, but they still haven't been designed specifically for functional programming. Functional programming is much more expressive than object-oriented programming. It has its own design patterns that help to make the life of a programmer easier. We will focus on:

  • Monoids
  • Monads
  • Functors

After we've looked at some Scala functional programming concepts, and we've been through these, we will mention some interesting design patterns from the Scala world.

A brief explanation of the preceding listed patterns will follow in the next few subsections.

Monoids

Monoid is a concept that comes from mathematics. We will take a look at it in more detail with all the theory needed to understand it later in this book. For now, it will be enough to remember that a monoid is an algebraic structure with a single associative binary operation and an identity element. Here are the keywords that you should remember:

  • The associative binary operation. This means (a+b)+c = a+(b+c).
  • The identity element. This means a+i = i+a = a. Here, the identity is i.

What is important about monoids is that they give us the possibility to work with many different types of values in a common way. They allow us to convert pairwise operations to work with sequences; the associativity gives us the possibility for parallelization, and the identity element allows us to know what to do with empty lists. Monoids are great to easily describe and implement aggregations.

Monads

In functional programming, monads are structures that represent computations as sequences of steps. Monads are useful for building pipelines, adding operations with side effects cleanly to a language where everything is immutable, and implementing compositions. This definition might sound vague and unclear, but explaining monads in a few sentences seems to be something hard to achieve. Later in this book, we will focus on them and try and clear things up without the use of a complex mathematical theory. We will try to show why monads are useful and what they can help with, as long as developers understand them well.

Functors

Functors come from category theory, and as for monads, it takes time to explain them properly. We will look at functors later in this book. For now, you could remember that functors are things that can allow us to lift a function of the type A => B to a function of the type F[A] => F[B].

Scala-specific design patterns

The design patterns in this group could be assigned to some of the previous groups. However, they are specific to Scala and exploit some of the language features that we will focus on in this book, and so we've decided to place them in their own group.

We will focus our attention on the following:

  • The lens design pattern
  • The cake design pattern
  • Pimp my library
  • Stackable traits
  • The type class design pattern
  • Lazy evaluation
  • Partial functions
  • Implicit injection
  • Duck typing
  • Memoization

The next subsections will give you some brief information about these patterns before we properly study them later in this book.

The lens design pattern

The Scala programming language promotes immutability. Having objects immutable makes it harder to make mistakes. However, sometimes mutability is required and the lens design pattern helps us to achieve this nicely.

The cake design pattern

The cake design pattern is the Scala way to implement dependency injection. It is something that is used quite a lot in real-life applications, and there are numerous libraries that help developers achieve it. Scala has a way of doing this using language features, and this is what the cake design pattern is all about.

Pimp my library

Many times, engineers need to work with libraries, which are made to be as generic as possible. Sometimes, we need to do something more specific to our use case, though. The pimp my library design pattern provides a way to write extension methods for libraries, which we cannot modify. We can also use it for our own libraries as well. This design pattern also helps to achieve better code readability.

Stackable traits

Stackable traits is the Scala way to implement the decorator design pattern. It can also be used to compose functions, and it's based on a few advanced Scala features.

The type class design pattern

This design pattern allows us to write generic code by defining a behavior that must be supported by all members of a specific type class. For example, all numbers must support the addition and subtraction operations.

Lazy evaluation

Often, engineers have to deal with operations that are slow and/or expensive. Sometimes, the result of these operations might not even be needed. Lazy evaluation is a technique that postpones the operation execution until it is actually needed. It could be used for application optimization.

Partial functions

Mathematics and functional programming are really close together. As a consequence, some functions exist that are only defined for a subset of all the possible input values they can get. A popular example is the square root function, which only works for non-negative numbers. In Scala, such functions can be used to efficiently perform multiple operations at the same time or to compose functions.

Implicit injection

Implicit injection is based on the implicit functionality of the Scala programming language. It automatically injects objects whenever they are needed, as long as they exist in a specific scope. It can be used for many things, including dependency injection.

Duck typing

This is a feature that is available in Scala and is similar to what some dynamic languages provide. It allows developers to write code that requires the callers to have some specific methods (but not implement an interface). When someone uses a method with a duck type, it is actually checked during compile time whether the parameters are valid.

Memoization

This design pattern helps with optimization by remembering function results, based on the inputs. This means that as long as the function is stable and will return the same result when the same parameters are passed, one can remember its results and simply return them for every consecutive identical call.

 

Choosing a design pattern


As we already saw, there are a huge number of design patterns. In many cases, they are suitable to be used in combinations as well. Unfortunately, there is no definite answer regarding how to choose the concept of designing our code. There are many factors that could affect the final decision, and you should ask yourselves the following questions:

  • Is this piece of code going to be fairly static or will it change in the future?
  • Do we have to dynamically decide what algorithms to use?
  • Is our code going to be used by others?
  • Do we have an agreed interface?
  • What libraries are we planning to use, if any?
  • Are there any special performance requirements or limitations?

This is by no means an exhaustive list of questions. There is a huge amount of factors that could dictate our decision in how we build our systems. It is, however, really important to have a clear specification, and if something seems missing, it should always be checked first.

In the rest of the chapters, we will try to give specific recommendations about when a design pattern should and should not be used. They should help you ask the right questions and take the right decision before going on and writing code.

 

Setting up the development environment


This book will aim to give real code examples for you to run and experiment with. As well as showing the most important code snippets in the pages of the book, you will have access to the code both from Packt Publishing as well as through GitHub for your convenience. The repository can be found at https://github.com/nikolovivan/scala-design-patterns-v2.

Having code examples means that it is important to be able to easily run any examples we have provided here and not to fight with the code. We will do our best to have the code tested and properly packaged, but you should also make sure that you have everything needed to run the examples.

Installing Scala

Of course, you will need the Scala programming language. It does require Java to be installed, it evolves quickly, and the newest version can be found at https://www.scala-lang.org/download/. There are different ways of installing the language and you can choose whichever is the most comfortable for you. There are a few tips about how to install the language in your operating system at https://www.scala-lang.org/download/install.html. As the official Scala website suggests, the easiest way to get started is to download an IDE (IntelliJ, for example), get the Scala plugin, and it will set things up for you. I will provide a couple of tips that have proven useful in my career that have enabled me to be very flexible while experimenting and learning.

Tips for installing Scala manually

You can always download multiple versions of Scala and experiment with them. I use Linux and my tips will be applicable to Mac OS users, too. Windows users can also do a similar setup. Here are the steps:

  1. Install Scala under /opt/scala-{version}/ or any other path you prefer.
  2. Create a symlink using this command: sudo ln -s /opt/scala-{version} scala-current. This can make switching versions much easier, if you decide to experiment.
  3. Add the path to the Scala bin folder to your .bashrc (or equivalent) file using the following lines:
  •  export SCALA_HOME=/opt/scala-current
  •  export PATH=$PATH:$SCALA_HOME/bin

Now if you had defined a symlink and you decide to install another version of Scala, you could simply redefine the existing symlink and you can go on with your real work.

Note

If you don't want to go through the hassle of installing Scala manually or you find that you often switch to different versions of the language, SBT might be a more comfortable option.

Tips for installing Scala using SBT

You can also experiment with any Scala version using SBT. To do this, you should:

  1. Download and install SBT: https://www.scala-sbt.org/download.html.
  2. Open a Terminal and run sbt.
  3. In the SBT shell, type ++ 2.12.4 or any version you want to try. Please note that if the currently used Scala version is not binary compatible with the one you want to use, you will have to modify the command to the following—++ 2.12.4!. Binary compatibility is very important in Scala and you should try and make sure they use libraries written in the same version of Scala as they use. Otherwise, you might get into trouble.
  4. Issue the console command and you will be in a Scala shell running the version of your choice.

Note

All the examples in this book use SBT or Maven (depending on your preferences). They are build and dependency management tools, which means that you might not even need to do anything extra to install Scala. You can just import an example project and everything will be taken care of automatically.

Scala IDEs

There are multiple IDEs out there that support development in Scala. There is absolutely no preference about which one to use to work with the code. Some of the most popular ones are as follows:

  • IntelliJ
  • Eclipse
  • NetBeans

IntelliJ is currently the one recommended on the Scala website and probably the most used one at the time of writing. All of those IDEs use plugins to work with Scala, and downloading and using them should be straightforward.

Dependency management

Running most of the examples in this book will not require any additional dependencies in terms of special libraries. In some cases, though, we might need to show how a Scala code is unit tested, which will require us to use a testing framework. Also, we will later present some real-life use cases in which an additional library is used. Dealing with dependencies nowadays is done using specialized tools. They usually are interchangeable, and which one to use is a personal choice. The most popular tool used with Scala projects is SBT, but Maven is also an option, and there are many others out there as well. The former is normally used when a project is started from scratch and Scala is the main programming language. The latter could be useful in cases when the main language used is Java, for example, and we want to add modules written in Scala.

Modern IDEs provide the functionality to generate the required build configuration files, but we will give some generic examples that could be useful not only here, but in future projects. Depending on the IDE you prefer, you might need to install some extra plugins to have things up and running, and a quick Google search should help.

SBT

SBT stands for Simple Build Tool and it uses the Scala syntax to define how a project is built, managing dependencies, and so on. It uses .sbt files for this purpose. It also supports a setup based on Scala code in .scala files, as well as a mix of both.

To download SBT, go to http://www.scala-sbt.org/1.0/docs/Setup.html and follow the instructions. If you wish to obtain the newest version, then simply Google it and use the result you get back.

The following screenshot shows the structure of a skeleton SBT project:

It is important to show the contents of the main .sbt files.

The version.sbt file looks as follows:

version in ThisBuild := "1.0.0-SNAPSHOT"

It contains the current version that is automatically incremented if a release is made.

The assembly.sbt file has the following content:

assemblyMergeStrategy in assembly := {
   case PathList("javax", "servlet", xs @ _*)         => MergeStrategy.first
   case PathList(ps @ _*) if ps.last endsWith ".html" => MergeStrategy.first
   case "application.conf"                            => MergeStrategy.concat
   case "unwanted.txt"                                => MergeStrategy.discard
   case x =>
     val oldStrategy = (assemblyMergeStrategy in assembly).value
     oldStrategy(x)
 }

 assemblyJarName in assembly := { s"${name.value}_${scalaVersion.value}-${version.value}-assembly.jar" }

 artifact in (Compile, assembly) := {
   val art = (artifact in (Compile, assembly)).value
   art.withClassifier(Some("assembly"))
 }

 addArtifact(artifact in (Compile, assembly), assembly)

It contains information about how to build the assembly JAR—a merge strategy, final JAR name, and so on. It uses a plugin called sbtassembly (https://github.com/sbt/sbt-assembly).

The build.sbt file is the file that contains the dependencies of the project, some extra information about the compiler, and metadata. The skeleton file looks as follows:

organization := "com.ivan.nikolov"

 name := "skeleton-sbt"

 scalaVersion := "2.12.4"

 scalacOptions := Seq("-unchecked", "-deprecation", "-encoding", "utf8")

 javaOptions ++= Seq("-target", "1.8", "-source", "1.8")

 publishMavenStyle := true

 libraryDependencies ++= {
   val sparkVersion = "2.2.0"
   Seq(
     "org.apache.spark" % "spark-core_2.11" % sparkVersion % "provided",
     "com.datastax.spark" % "spark-cassandra-connector_2.11" % "2.0.5",
     "org.scalatest" %% "scalatest" % "3.0.4" % "test",
     "org.mockito" % "mockito-all" % "1.10.19" % "test" // mockito for tests
   )
 }

As you can see, here we define the Java version against which we compile some manifest information and the library dependencies.

The dependencies for our project are defined in the libraryDependencies section of our SBT file. They have the following format:

"groupId" %[%] "artifactId" % "version" [% "scope"]

If we decide to separate groupId and artifactId with %% instead of %, SBT will automatically use scalaVersion and append _2.12 (for Scala 2.12.*) to artifactId. This syntax is usually used when we include dependencies written in Scala, as the convention there requires us to have the Scala version added as part of artifactId. We can, of course, manually append the Scala version to artifactId and use %. This is also done in cases when we import libraries written in a different major version of Scala. In the latter case, however, we need to be careful with binary compatibility. Of course, not all libraries will be written in the version we use, so we either have to thoroughly test them and make sure they won't break our application, change our Scala version, or look for alternatives.

Note

The dependencies shown will not be needed at any point in this book (the one for Spark and the Datastax one). They are here just for illustration purposes, and you can safely remove them if not needed.

SBT requires each statement to be on a new line and to be separated with a blank line from the previous one if we work with .sbt files. When using .scala files, we just write code in Scala.

The %% syntax in the dependencies is a syntactic sugar, which, using scalaVersion, will replace the name of the library, for example, scalatest will become scalatest_2.12 in our case.

SBT allows the engineer to express the same things differently. One example is the preceding dependencies—instead of adding a sequence of dependencies, we can add them one by one. The final result will be the same. There is also a lot of flexibility with other parts of SBT. For more information on SBT, refer to the documentation.

The project/build.properties defines the sbt version to be used when building and interacting with the application under sbt. It is as simple as the following:

sbt.version = 1.1.0

Finally, there is the project/plugins.sbt file that defines different plugins used to get things up and running. We already mentioned sbtassembly:

addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.5")

Note

There are different plugins online that provide useful functionalities. Here are some common sbt commands that can be run from the root folder in the Terminal of this skeleton project:

  • sbt: This opens the sbt console for the current project. All of the commands that will follow can be issued from here by omitting the sbt keyword.
  • sbt test: This runs the application unit tests.
  • sbt compile: This compiles the application.
  • sbt assembly: This creates an assembly of the application (a fat JAR) that can be used to run as any other Java JAR.

Maven

Maven holds its configuration in files named pom.xml. It supports multimodule projects easily, while for sbt, there needs to be some extra work done. In Maven, each module simply has its own child pom.xml file.

To download Maven, go to https://maven.apache.org/download.cgi.

The following screenshot shows the structure of a skeleton Maven project:

The main pom.xml file is much longer than the preceding SBT solution. Let's have a look at its parts separately.

There is usually some metadata about the project and different properties that can be used in the POM files in the beginning:

<modelVersion>4.0.0</modelVersion>
<groupId>com.ivan.nikolov</groupId>
<artifactId>skeleton-mvn</artifactId>
<version>1.0.0-SNAPSHOT</version>
<properties>
    <scala.version>2.12.4</scala.version>
    <scalatest.version>3.0.4</scalatest.version>
    <spark.version>2.2.0</spark.version>
</properties>

Then, there are the dependencies:

<dependencies>
    <dependency>
        <groupId>org.apache.spark</groupId>
        <artifactId>spark-core_2.11</artifactId>
        <version>${spark.version}</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>com.datastax.spark</groupId>
        <artifactId>spark-cassandra-connector_2.11</artifactId>
        <version>2.0.5</version>
    </dependency>
    <dependency>
        <groupId>org.scala-lang</groupId>
        <artifactId>scala-library</artifactId>
        <version>${scala.version}</version>
    </dependency>
    <dependency>
        <groupId>org.scalatest</groupId>
        <artifactId>scalatest_2.12</artifactId>
        <version>${scalatest.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-all</artifactId>
        <version>1.10.19</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Finally, there are the build definitions. Here, we can use various plugins to do different things with our project and give hints to the compiler. The build definitions are enclosed in the <build> tags.

First, we specify some resources:

<sourceDirectory>src/main/scala</sourceDirectory>
<testSourceDirectory>src/test/scala</testSourceDirectory>
<resources>
    <resource>
        <directory>${basedir}/src/main/resources</directory>
    </resource>
</resources>

The first plugin we have used is scala-maven-plugin, which is used when working with Scala and Maven:

<plugin>
    <groupId>net.alchim31.maven</groupId>
    <artifactId>scala-maven-plugin</artifactId>
    <version>3.3.1</version>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>testCompile</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <scalaVersion>${scala.version}</scalaVersion>
    </configuration>
</plugin>

Another plugin we use is maven-assembly-plugin, which is used for building the fat JAR of the application:

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>3.1.0</version>
    <configuration>
        <appendAssemblyId>false</appendAssemblyId>
        <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
        </descriptorRefs>
    </configuration>
    <executions>
        <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
</plugin>

The complete pom.xml file is equivalent to the preceding sbt files that we presented.

As before, the Spark and Datastax dependencies are here just for illustration purposes.

Note

The use of JUnit to run unit tests in Scala 2.12 If you look into the dependencies in more depth, you will see that we have imported junit, which is a Java testing framework. At first glance, someone might think that we don't actually need it. However, there is a catch. A quick Google search about how to run Scalatest unit tests with Maven would point to resources recommending the use of scalatest-maven-plugin. If we followed those instructions and tried running some tests from the command line, we would get a strange error. This is due to the fact that we used Scala 2.12 and the scalatest-maven-plugin at its current version is not binary compatible with this version of the language.Like many things in software engineering, we have to find workarounds. Here, we could do two things:

  • Use an older version of Scala.
  • Force Maven to run our tests.Of course, the second option is the more desirable. This means that the only thing we need to do in each Scalatest we write is to add the following annotation to each test class: @RunWith(classOf[JUnitRunner]) and make sure our test classes contain the word Test in their name.

Similarly to SBT, you can use Maven from the command line. Some of the commands you might find most useful with the example projects in this book are shown in the next tip.

Note

Useful Maven commands:

  • mvn clean test: This runs the application unit tests
  • mvn clean compile: This compiles the application
  • mvn clean package: This creates an assembly of the application (a fat JAR) that can be used to run as any other Java JAR

SBT versus Maven

In this book, we will be using both SBT and Maven for dependency management and creating our projects. They are interchangeable, and our source code will not depend on which build system we choose. You can easily translate the .pom files to .sbt files using the skeleton that we've provided. The only difference will really be the dependencies and how they are expressed.

 

Summary


By now, we have a fair idea about what a design pattern means and how it can affect the way we write our code. We've iterated through the most famous design patterns out there, and we have outlined the main differences between them. We saw that in many cases, we could use Scala's features in order to make a pattern obsolete, simpler, or different to implement compared to the classical case for pure object-oriented languages. This book will show you how Scala makes it easier to write high-quality code.

Knowing what to look for when picking a design pattern is important, and you should already know what specific details to watch out for and how important specifications are.

Last but not least, we advise you to run the examples in this book, and we have provided some pointers that should make this really easy. In some cases, creating a complete solution using SBT or Maven might be too much hassle and somewhat unnecessary, but we believe it is a good practice to follow. Additionally, the approaches we explained are used throughout the industry and will be beneficial outside the scope of this book.

In the next chapter, we will get straight to the practical part of this book, where we will look at traits and mixing compositions, what they are useful for, and how and when to use them.

About the Author

  • Ivan Nikolov

    Ivan Nikolov is a technical architect based in London. He works in the ad tech industry and uses Scala in combination with libraries and technologies such as Spark, Hadoop, RabbitMQ, Kafka, SQL and NoSQL stores, and Akka. He also uses other JVM and scripting languages. Some of the projects Ivan has worked on include a large-scale real-time machine learning platform, batch processing solutions, and high load APIs. Ivan also likes getting involved with open source projects, whether it be to contribute or get inspiration and good ideas.

    Browse publications by this author

Latest Reviews

(4 reviews total)
Useful information about design patterns with Scala
I have understood many things in Scala and Functional Programming.
Explains things in a thorough manner

Recommended For You

Learn Scala Programming

A step-by-step guide in building high-performance scalable applications with the latest features of Scala.

By Slava Schmidt
Modern Scala Projects

Develop robust, Scala-powered projects with the help of machine learning libraries such as SparkML to harvest meaningful insight

By Ilango Gurusamy
C# 8.0 and .NET Core 3.0 – Modern Cross-Platform Development - Fourth Edition

Learn the fundamentals, practical applications, and latest features of C# 8.0 and .NET Core 3.0 from expert teacher Mark J. Price.

By Mark J. Price
Expert Python Programming - Third Edition

Refine your Python programming skills and build professional grade applications with this comprehensive guide

By Michał Jaworski and 1 more