We have come a long way in the world of design patterns in Scala. We saw some classical Gang of Four design patterns from the point of view of Scala, as well as features that are applicable specifically to this programming language. By now, you should have enough knowledge in order to build high quality, extendible, efficient, and elegant applications. Everything we have covered until now, if taken into consideration, should have a really positive impact on any application you will create.
Many of the things you saw in this book we wrote from scratch. This is really helpful in terms of understanding a given concept, but it takes time, and in real-world applications, using a library that gives us some functionalities is usually preferred. There are a number of different libraries available, which are accessible through a simple Google search and address just about anything you can think of. Except the fact that this could save a lot of time, it also means that we integrate into our code thoroughly tested components that are trusted by many others. This, of course, depends on the library we are trying to incorporate, but as long as it brings something useful to the community, it will most likely be reliable. Having said all that, our main focus of this chapter will include the following:
- The Scalaz library
- Writing a complete application
- Summarizing what we learned so far
There are a lot of libraries for Scala out there and some might consider other libraries to be much more important to the language than Scalaz is. There are alternatives as well, which have spun up due to various reasons. We will, however, focus on Scalaz here, as it is generally used when someone wants to implement concepts such as monoids, functors, and monads in their application. And these concepts are really important in functional programming as we saw earlier. We will also write a complete application that uses some of the techniques and design patterns we became familiar with in the previous chapters. This chapter will give some insights into how applications should be structured and how to understand our requirements and then build the solutions for them properly. Finally, we will summarize everything we learned here.
Writing software applications will inevitably bring developers to the point where they will have to implement something that already exists. Reinventing the wheel is generally a bad idea unless we have some extremely specific and strict requirements that no library in the world satisfies, or if there is a good reason not to include a specific dependency in our project.
People write libraries to deal with all kinds of problems in software. In a community such as the open source one, libraries are shared and everyone can use or contribute to them. This brings a lot of benefits and the main benefit is that code becomes more mature, better tested, and more reliable. However, sometimes this also makes things harder—many people will create the same library and it becomes difficult to understand which one is the most suitable.
Despite the fact that there could be multiple implementations of the same library, using one is the way to go when we write enterprise applications. Filtering out the bad ones from the good ones is easy nowadays—if a library is good, many people will use it. If it's bad, people will avoid it. If there are multiple good ones, developers will have to spend some time investigating which one is the most suitable for their use case.