Patterns, Patterns All Around
During the 1990s object-oriented programming was beginning to take the software world by storm. C++ and Java were some of the most popular programming languages. Walking into a bookstore and browsing to the computer section you would find books of all sorts on object-oriented development and design. One of the seminal books to come out during this period was, “Design Patterns: Elements of Reusable Object-Oriented Software”. This book and its later derivatives are some of my favorites.
I love to look at pattern books and see how items are implemented in different languages. It helps me to compare and contrast how languages work.
Patterns usually fit in one of 3 categories:
- Creational – Used to create objects (example: Factory)
- Behavioral – Based on behaviors (example: Observer)
- Structural – Used a some sort of scaffolding (example: Facade)
Patterns for the Worse
Developers started using patterns to define software instead of applying patterns that make sense. Software became really hard to maintain, because “every class must have an interface” or “you can’t create an object without a factory”. I was on a project in the early 2000s and the developer just wanted to talk about the patterns he was using instead of the problem he was solving. Applying patterns became a developer badge of honor no matter if they made sense or not.
The over use of patterns still rears its head today. Reactive programming is all the rage, but does it make things simpler in every situation? Patterns are important and should solve a problem. The solution shouldn’t be changed to fix the pattern. Patterns should only be applied if they make the solution simpler and easier to understand.
During my day to day development, I still see problems that fit patterns really well. In my next rant on patterns, I plan on discussing the “Singleton” pattern. This is a very easy pattern to implement and can be used in a lot of situations, however it does have some gotchas!