Patterns Part Deux - A Rusty Duck
Last week we discussed some of the design patterns we've been studying. We shuffled those poor ducks around a lot! We did finally land on the Singleton Pattern. The Singleton restricts the instantiation of a class to one "single" instance. Also providing a single point of access to the instance. Wait, is that our new type of duck, The Singleton Duck?
How would that work? Is Singleton Duck like Leisure Suit Duck? Just more aloof and dapper? Ok let's not get carried away with the ducks. The Singleton design pattern is part of the Creational group of patterns. Design Patterns are typically broken out into three general categories:
Creational patterns - these provide object creation mechanisms that promote flexibility and reuse of code.
Structural patterns - these patterns show how to assemble objects and classes into larger structures while keeping the structures flexible and efficient.
Behavioral patterns - these take care of effective communication and assigning responsibility between objects.
What's similar between these three categories? At their core they all promote flexibility and efficiency. Is this why we use design patterns? Well, to some degree yes. Design patterns can be thought of as tried and true solutions to common problems in software design. Over on [Refacturing.guru](https://refactoring.guru/design-patterns) they show 22 designs patterns that fall into the three categories above. Shall we dig into all 22 of them? How about, instead of me typing each one out with a description, you head on over there and check it out.
One of the things I found helpful with the information on Refactoring.guru is the description and breakdown of each of the patterns. Here’s a high-level what each pattern contains from Refactoring.guru. Each pattern starts off with a description (the Intent) and has the following sections:
How to implement
Pros and Cons
Relations with other patterns
The real-world analogy helped to solidify the concepts and I found the pseudo-code helpful. Sticking with Singleton pattern here is the How to Implement section from Refactoring.guru:
How to Implement
1. Add a private static field to the class for storing the singleton instance.
2. Declare a public static creation method for getting the singleton instance.
3. Implement “lazy initialization” inside the static method. It should create a new object on its first call and put it into the static field. The method should always return that instance on all subsequent calls.
4. Make the constructor of the class private. The static method of the class will still be able to call the constructor, but not the other objects.
5. Go over the client code and replace all direct calls to the singleton’s constructor with calls to its static creation method.
Pretty straight forward right? Knowing that these design patterns exist, not necessarily memorizing them, and understanding their benefits is a handy tool to have in your box of tricks. Which brings up next weeks topic: Utility Belt – Accessory or Fashion Necessity?
Don’t forget to check out [Refacturing.guru](https://refactoring.guru/design-patterns) !