If you’re an experienced software developer, you’ve probably heard about Design Patterns. But if you are just starting, don’t worry, it’s OK.
What is not okay is to ignore that they exist. Do not use them when you shouldn’t or get the wrong interpretation of them.
What Is a Design Pattern?
You’re Right if You Think That…
- You should use them when needed to keep your code simpler than if you don’t.
- They are a general solution for known problems but they’re adapted according your needs.
- They are helpful to make code more expressive and less complex.
It’s a general reusable solution that can be applied to commonly occurring problems in software development.
They are proven solutions. They are expressive and make things easy to maintain. Since many developers are familiar with Design Patterns, we can say it’s kind of a development standard.
You’re Lost if You Think That…
- You should use them only because people say it’s cool.
- No matter the situation, they’re always the best option ever.
- If you don’t apply Design Patterns you’re a bad developer.
Remember, they are language neutral, so they can be applied to any technology. Also, Design Patterns are not associated to project size.
What Are the Elements of Design Patterns?
- Pattern Name
- The name should be descriptive enough to know what we’re talking about.
- Describes the general problem or situation to resolve.
- Describes the general solution to be implemented.
- Describes the good and bad things that will happen if we implement it.
What Are the Categories of Design Patterns?
- Creational Design Patterns
- They provide the techniques to create objects. Examples, Singleton, Abstract Factory, and Builder Pattern.
- Structural Design Patterns.
- They describe the composition of the objects and their organization. Examples, Adapter Pattern, and Decorator Pattern.
- Behavioral Design Patterns
- They focus on improving the communication between objects in a system. Examples, Iterator Pattern, Observer Pattern, and Strategy Pattern.
Be Careful of the Dark Side… the Antipatterns!
An Antipattern is an ineffective response to a recurring problem. Typically, it has more bad consequences than good ones.
The worst is the God classes. They can control many other classes and have many dependencies and lots of responsibilities. God classes tend to grow to the point of becoming maintenance nightmares.
Have you ever seen or, even worst, created a God class? Don’t do it and if you see any please kill it (or refactor as required).
- Design Patterns: Elements of Reusable Object-Oriented Software by John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma
- Head First Design Patterns by Elisabeth Freeman
So now you know a little bit more about Design Patterns. You’re ready to join the vast group of developers already using them. Use your new knowledge wisely.