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.
A formal definition for design patterns will allow you to understand the value of using good practice in building elegant and efficient software.
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, which helps solving the particular problem or family of problems.
Design patterns are best practices, to which the software community has arrived over a period of time. They are supposed to help write efficient, readable, testable, and easily extendable code. In some cases, they can be a 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, which 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, which 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
Everybody needs design patterns and should look into some before writing code. As we mentioned earlier, they help writing efficient, readable, extendable, and testable code. All these features are really important to companies in the industry.
Even though in some cases it is preferred 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 to algorithms, design patterns could also affect it. A simple example could be an object, which takes a long time to instantiate, and instances are used in many places in an application, but could be made singleton instead. You will see more concrete examples in the later chapters of this book.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Hungary
Philippines
Mexico
Thailand
Ukraine
Luxembourg
Estonia
Lithuania
Norway
Chile
South Korea
Ecuador
Colombia
Taiwan
Switzerland
Indonesia
Cyprus
Denmark
Finland
Poland
Malta
Czechia
New Zealand
Austria
Turkey
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Malaysia
South Africa
Netherlands
Bulgaria
Latvia
Japan
Slovakia
4
