59: Design Patterns: Factory.

As object-oriented software has evolved over the years, quite a few solutions to specific problems have also adapted and gained wide adoption. In 1995, a book called “Design Patterns: Elements of Reusable Object-Oriented Software” documented 23 patterns and started a new way to describe software that would be understandable to other developers. This book was written by four authors, Erich Gamma, Richard Helm, Ralph Johnson, and John Glissades, who are often referred to as the Gang of Four. The book is also sometimes just referred to as the Gang of Four book or just the GoF book. When you learn how to make use of these patterns, your software will become more flexible and easier to maintain as new features are added. This episode introduces patterns and then describes the factory pattern. The code example given in the episode describes a base class called Dungeon that makes use of a base class called Monster. There can be different types of monsters just like there can be different types of dungeons. The base Dungeon class doesn’t know what specific Monster class to create so instead it declares a virtual method called createMonster. This method could have a default implementation or it could be pure virtual. That’s up to you. The main thing is that a specific dungeon class, let’s say a MountainCave class that derives from Dungeon, overrides the createMonster method to create some specific instance that derives from the Monster class. By deriving from the Dungeon class, you can change the type of monster that gets created. This is the factory pattern. The createMonster method is called the factory method. Listen for more or you can also read the full transcript below. Transcript Look around at almost anything nearby and think about what similar items looked like 10 years ago. Or 20 years ago. Or more. Sure, some things haven’t changed at all since they were first invented and it’s also possible to buy things with a retro look. But most things adapt and get better and add more features. They become faster, smaller, and lighter. Even things designed to be heavy such as a hammer have changed over the years. I still remember the days when before I could use a hammer, I had to check to make sure the head was firmly attached to the handle. Let’s say that you wanted to build a new hammer. Would you start from the very beginning and create a design that would have been modern before electricity was widely available? No. You should add your new idea to a modern design. The same thing applies to software design. With software, though, this is even more important. Because when you release your first version, you’re going to be under pressure to get it out fast and with as few features as possible. If you’re not using well established patterns, then you’re going to have a lot more trouble adding new features for version 2. This is because many of the patterns are not something that any of us would write on our first attempt. Especially when we’re under pressure to get something done. We’re likely to create something that looks modern but is written like it was a rock tied to a stick. And that’s one of the best things about design patterns. They can actually help speed up the process and prepare the software for future growth because each pattern is already well designed. Recognizing opportunities for applying patterns is another area that the Design Patterns book helps because for each pattern, the authors describe the problem, the solution, and give you enough guidance to judge for yourself if the pattern will help. There’s nothing new in the design patterns book. But what it did was bring together 23 well tested and widely applicable solutions and set an example for how other patterns should be documented. The patterns in the book have become well known by consistent names and this has helped standardize how software engineers describe solutions to