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.

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.