Over the past 3 weeks, I've been teaching myself fundamental design patterns in hope of gaining some insight in common development practices being used in the industry today. In fact, I've been asked about design patterns more frequently than ever before. It seems companies are shifting their focus from whiteboard leetcode types of questions to one's understanding of design patterns, how they would build a system given constraints, and something along the line, when interviewing candidates.
Why Design Patterns?
Someone has already solved your problems
- You can exploit the wisdom and lessons learned by other developers who've been down the same design problem road and survived the trip!
When you communicate using patterns, you're doing more than just sharing LINGO
- Shared pattern vocabularies are POWERFUL!
- Patterns allow you to say more with less!
- Talking at the pattern level allows you to keep the discussion at the design level, without having to dive down to the nitty gritty details of implementing objects and classes!
- Shared vocabularies encourage more junior developers to get up to speed and turbo charge your development team!
There're few tedious terminologies that you can quickly remind yourself.
- A pattern is a solution to a problem in a context.
- A context is the situation in which the pattern applies. This should be a recurring situation.
- A problem refers to the goal you're trying to achieve in a context, but it also refers to any constraints that occur in the context.
- A solution is what you're after; a general design that anyone can apply which resolves the goal and set of constraints.
The Fourteen Shades of Patterns
Here's the overall summary of design patterns I've learned. There're more than 14 design patterns. However, these patterns will be enough to give you power to make your own designs! I linked each pattern with corresponding posts. It is my hope that you also learn about design patterns through my posts and drive the industry with your one-of-kind strategies!
- It wraps an object to provide new behaviour
- It encapsulates state-based behaviours and uses delegation to switch between behaviours
- It provides a way to traverse a collection of objects without exposing its implementation
- It simplifies the interface of a set of classes
- It encapsulates interchangeable behaviours and uses delegation to decide which one to use
- It wraps an object to control access to it
- Subclasses decide which concrete classes to create
- It wraps an object and provides a different interface to it
- It allows objects to be notified when state changes
Template Method Pattern
- Subclasses decide how to implement steps in an algorithm
- Clients treat collections of objects and individual objects uniformly
- It ensures one and only object is created
Abstract Factory Pattern
- It allows a client to create families of objects without specifying their concrete classes
- It encapsulates a request as an object