cobblestone pathway

Patterns Revisited Part 1

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.

Applying Patterns

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!

Related Articles

LT Anniversary Logo

Lean TECHniques was founded on April 1st, 2011 by Tim Gifford and Brandon Carlson. Their work within the community led to frequent consulting requests. They wanted to help organizations of all sizes with their Agile needs, and do so while creating a place people loved to work.

Great software project teams are able to produce application features quickly that provide users with the most amount of value. If you don’t have a UI/UX designer on your team, you’re risking the design of your application experience short-changing your users.

There are so many risks when we make changes to software systems. A defect can cause a minor frustration, cause a loss of 440 million USD in 45 minutes, and put Knight Capital Group out of business or worse.

php code on computer screen

Lean TECHniques, a software consultancy, has announced a strategic investment in Boon Logic, an unsupervised machine learning company.