This is the most popular single guy in the neighborhood. Everybody knows him, everybody talks about him, and anybody can find him easily.

Even people who will frown when other design patterns are mentioned will know it by name. At some point, it was even proclaimed an anti-pattern, but only because of its wide popularity. So, for those who are hearing about it for the first time, what is this pattern about?

Usually, if you have an object, you can create as many of its instances as you want. Say, for example, you have the Cat class:

class Cat

You can produce as many of its instances (cats, to be precise), as you want:

val firstCat = Cat()
val secondCat = Cat()
val yetAnotherCat = Cat()

And there's no problem with that.

What if we wanted to disallow such behavior? Clearly, we have to create an object in some way for the first time. But from the second time on, we...

The Factory Method is all about creating objects. But why do we need a method to create objects? Isn't it what constructors are all about?

Well, constructors have their inherent limitations, which we're about to discuss.

We'll start with the Factory Method formalized in the book Design Patterns by Gang of Four.

This is one of the first patterns I teach my students. They're usually very anxious about the whole concept of design patterns, since it has an aura of mystery and complexity. So, what I do is ask them the following question.

Assume you have some class declaration, for example:

class Cat {
    val name = "Cat"
}

Could you write a function that returns a new instance...

Abstract Factory is a greatly misunderstood pattern. It has a notorious reputation for being very complex and bizarre but actually, it's quite simple. If you understood the Factory Method, you'll understand this one in no time. This is because Abstract Factory is a factory of factories. That's all there is to it, really. The factory is a function or class that's able to create other classes. Abstract Factory is a class that creates factories.

You may understand that and still wonder what the usages of such a pattern may be. The main usage of Abstract Factory in the real world would probably be frameworks, most notably Spring Framework, which uses the notion of Abstract Factory to create its components out of annotations and XML files. But since creating our own framework may be quite tiresome, let's take another example where this pattern...

Sometimes, our objects are very simple, and have only one constructor, be it an empty or non-empty one. But sometimes, their creation is very complex, and based on a lot of parameters. We've seen one pattern already that provides a better constructor—the Static Factory Method design pattern. Now, we'll discuss Builder design pattern, which is somewhat similar and somewhat different.

As a software architect, one of my main channels of communication is email. Probably this is true of most software development roles.

An email has the following:

• An address (at least one is mandatory)
• CC (zero or more, optional)
• Title (optional)
• Body (optional)
• Attachment (zero or more, optional)

Let...

This design pattern is all about customization and creating objects that are similar but slightly different. To understand it better, we'll start with an example.

Imagine that you have a shop where you sell PCs.

Regular PC consists of the foll:

• Motherboard
• CPU
• Graphical card
• RAM

Most of your customers don't actually care what components you put in this PC. What they do care about is whether this PC will be able to run Magnificent Pilfering Car 7 at 60fps (which is frame per second).

So, you decide to build it like that:

data class PC(val motherboard: String = "Terasus XZ27",
             val cpu: String = "Until Atom K500",
             val ram: String = "8GB...

In this chapter, we learned when and how to use design patterns from the Creational family. We learned about different usages of the object keyword: as Singleton, as a container for the Static Factory Methods, and as an anonymous implementation of an interface. We then saw the workings of the destructuring declaration and generics in Kotlin with the use of the in, out, and where keywords. We also learned about the default parameter values and named arguments, followed by the copy() function for data classes.

In the next chapter, we'll cover the second family of design patterns, Structural patterns. Those patterns help extend the functionality of our objects.