Chapter 1 , Ready… Steady…Go!, attempts to help newcomers to the Go programming language who have some background in any other programming language. It will begin by showing how to install the Go environment in a Linux machine, moving to syntax, type and flow control.

Chapter 2 , Creational Patterns - Singleton, Builder, Factory, Prototype, and Abstract Factory Design Patterns, introduces the problems that can arise when an object creation or management is particularly complex or expensive using the Singleton, Builder, Factory, and Abstract Factory design patterns.

Chapter 3 , Structural Patterns - Composite, Adapter, and Bridge Design Patterns, deals with the first set of Structural patterns about object composition to get some new functionality. Such as creating an intermediate object and using of various objects as if there is only one.

Chapter 4 , Structural Patterns - Proxy, Facade, Decorator, and Flyweight Design Patterns, is less oriented to multi-object composition but focuses more on obtaining new functionality in existing objects. The Decorator pattern is commonly used to follow the open-closed principle. Facade is extensively used in API’s where you want a single source for many sources of information and actions. Flyweight is not so common but it’s a very useful pattern when the memory is becoming a problem caused by a large collection of similar objects. Finally, the Proxy pattern wraps on an object to provide the same functionality, but at the same time, adding something to the proxy’s functionality.

Chapter 5 ,  Behavioral patterns - Strategy, Chain of Responsibility, Command, and Mediator Design Patterns, deals with the first behavioral pattern to make objects react in an expected or bounded way. We’ll start with the Strategy pattern, perhaps the most important design pattern in object-oriented programming, as many design patterns have something in common with it. Then we’ll move to the Chain of Responsibility to build chains of objects that can decide which between them must deal with a particular case. Finally, Command pattern to encapsulate actions that don’t necessarily need to be executed immediately or must be stored.

Chapter 6 , Behavioral Patterns - Template, Memento, and Interpreter Design Patterns, continues with Behavioral patterns introducing the Interpreter pattern, a quite complex pattern to create small languages and Interpreters for them. It can be very useful when a problem can be solved by inventing a small language for it. The Memento pattern is in front of our eyes every day with the Undo button in apps. The Template pattern helps developers by defining an initial structure of an operation so that the final users of the code can finish it.

Chapter 7 , Behavioral Patterns - Visitor, State, Mediator, and Observer Design Patterns, depicts the Observer pattern, an important pattern that is becoming tremendously popular in distributed systems and reactive programming. The Visitor pattern deals with complex hierarchies of objects where you need to apply a particular action depending on the object. Finally, the State pattern is commonly used in video games and finite state machines and allows an object to change its behavior depending on its own state.

Chapter 8 , Introduction to Go's Concurrency, explains with more detail the CSP concurrency model used in Go by going through some examples using Goroutines and channels, as well as mutexes and syncs.

Chapter 9 , Concurrency Patterns - Barrier, Future, and Pipeline Design Patterns, will introduce some of the CSP concurrency patterns that are idiomatic to the Go language by walking through some examples and explanations. These are small but really powerful patterns so we will provides a few examples of the use of each of them, as well as some schemas (if possible) that will make the understanding of each of them easier.

Chapter 10 ,  Concurrency Patterns -  Workers Pool, and Publish or Subscriber Design Patterns, talks about a couple of patterns with concurrent structures. We will explain every step in detail so you can follow the examples carefully. The idea is to learn patterns to design concurrent applications in idiomatic Go. We are using channels and Goroutines heavily, instead of locks or sharing variables.

Most of the chapters in this book are written following a simple TDD approach, here the requirements are written first, followed by some unit tests and finally the code that satisfies those requirements. We will use only tools that comes with the standard library of Go as a way to better understand the language and its possibilities. This idea is key to follow the book and understanding the way that Go solves problems, especially in distributed systems and concurrent applications.

This book is for both beginners and advanced-level developers in the Go programming language. No knowledge of design patterns is expected.

In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.

Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "we need a main function to use it as libraries cannot be converted to executable files directly."

A block of code is set as follows:

    package main

    func main() {
      ten := 10
      if ten == 20 {
        println("This shouldn't be printed as 10 isn't equal to 20")
      } else {
        println("Ten is not equals to 20")
      }
    }

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

    if "a" == "b" || 10 == 10 || true == false {
      println("10 is equal to 10")
    } else if 11 == 11 && "go" == "go" {
        println("This won't because previous condition was satisfied")
      }
    }

Any command-line input or output is written as follows:

$ go run main.go

New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "In order to download new modules, we will go to Files | Settings | Project Name | Project Interpreter."

Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.