What is a Design Pattern
A design pattern is a proven, named answer to a problem that keeps coming up in software design. Patterns are grouped as creational, structural and behavioral, and you've already used several without knowing their names: Singleton, Iterator, Observer, Dependency Injection and the DAO.
Apprentice · Software Development · OOP · Updated
After this lesson you can
- Explain what a design pattern is, and name patterns you've already used
Key takeaways
- A design pattern is a named, proven idea for a problem that keeps coming up, not code you copy or a library you install.
- The Gang of Four's patterns are creational (how objects are made), structural (how they're put together) or behavioral (how they talk).
- You've already used patterns: every
foreachis Iterator,AddSingletonis Singleton, andProductDaois a DAO. - Write the simple version first, and reach for a pattern only when you have the problem it solves.
Cooks don't invent a new way to thicken every sauce: they make a roux. The word stands for a whole technique, so one cook can say "start with a roux" and the other knows exactly what to do. Software has the same kind of shared recipes: design patterns.
A named answer to a common problem
A design pattern is a proven way to solve a problem that keeps coming up when you design software. It isn't code you copy, or a library you install. It's an idea, with a name, that you shape to fit your own code.
Each pattern describes:
- the problem: when you'd reach for it;
- the solution: which classes and objects play which parts;
- the trade-offs: what it costs you.
The names are the most useful part. "Let's put a factory in front of the notifiers" says in five words what would otherwise take a page.
Many of the best-known patterns come from a 1994 book, Design Patterns: Elements of Reusable Object-Oriented Software, by four authors known as the Gang of Four. It describes 23 patterns, in three groups:
| Group | About | Examples |
|---|---|---|
| Creational | How objects are made | Factory Method, Singleton, Builder |
| Structural | How classes and objects are put together | Adapter, Decorator, Facade |
| Behavioral | How objects talk and share work | Iterator, Observer, Strategy |
Patterns you've already used
You've been using patterns throughout this course:
| Pattern | Problem | Where you used it |
|---|---|---|
| Singleton | There should be exactly one of something, shared by everyone | AddSingleton in ASP.NET Core, and every @Service() in Angular |
| Iterator | Go through a collection without knowing how it's stored | Every foreach loop, over a list, an array or a dictionary |
| Observer | Let many parts react when something changes | Angular's signals and observables |
| Dependency Injection | A class shouldn't create what it depends on | Controllers asking for an IProductDao, components calling inject() |
| DAO (Data Access Object) | Keep SQL out of the rest of the app | ProductDao, CategoryDao, UserDao |
| Factory | Hide which class gets created, and how | AddScoped<IUserDao>(_ => new UserDao(connectionString)) |
| Strategy | Swap one way of doing something for another | IClock: the real clock in the app, a fake one in tests |
The next lessons look at two Gang of Four patterns closely: Factory Method and Iterator.
Use them, don't force them
Patterns are tools, not goals. A pattern earns its place when you have the problem it solves. Adding a factory to create one class that never changes only makes the code longer. A good habit: write the simple version first, and reach for a pattern when the code starts to strain, such as the same switch copied into three places.
Knowing the names pays off in interviews, too: "Which design patterns have you used?" is a common question, and you now have real answers.
Check yourself
1 question to try on the lesson page.
So what
A design pattern is a named, proven solution to a recurring design problem. You already use Singleton, Iterator, Observer, Dependency Injection, DAO, Factory and Strategy, and now you can call them by name.