Redux and The Command Pattern

There are two things I know for absolute certainty in the Software industry.

1. Frameworks Always Change

We’ve all been there.

The Vicious cycle:

If things always change, then as a Software Engineer your job is to constantly be learning and making the right bets in libraries or frameworks you decide to use.

2. Design Patterns are the foundation of Software Engineering

So if we know Frameworks always change, then we have to stick to the foundation of great software: Design Patterns.

Design patterns represent the best practices used by experienced software developers. Design Patterns teach you how to think. The main benefit of learning design patterns is that you can come up with solutions to your problems a lot faster and if your co-workers are aware of these patterns, everyone can speak the same language. Now I’m advocating Design Patterns, but they are not the end all be all of solutions. Its okay if you are not using every piece of a design pattern as long you have a better solution to your particular problem.

History Lesson

We can trace design patterns back to Christopher Alexander, author of Pattern Language. Alexander realized that certain methods, over time, created constructs to achieve efficiency. It was then, stemming from Alexander’s work, other publications started coming out. A great one to read is Design Patterns: Elements of Reusable Object-Oriented Software. This describes patterns that provided solutions to common software development problems.

A great book for JavaScript developers is by Addy Osmani. It’s available online here.

Command Pattern

The Command Pattern is a great pattern for architecting really clean decoupled systems. The motivation of this pattern is to execute some piece of business logic at some point in the future. The reason why I wanted to touch on the Command Pattern specifically is because I believe its the root pattern of Redux. Let’s get into the Command Pattern, then translate this to Redux.