In this final part of the Command Pattern series, we will talk about yet another improvement on top of the Command Processor Pattern. It is described in the paper Command Revisited. From now on, we will just refer to it as the Command Revisited Pattern. The paper is short and sweet but you might not find it to be to the point after the first glimpse. The most beautiful part of the Command Revisited Pattern is that it provides a new perspective on the general Command Pattern.
Design and Architecture
In Part I, we discussed the original Command Pattern from the GoF Design Patterns book. In Part II, let’s talk about the improved version from another less known book: Pattern-Oriented Software Architecture Vol.1 (POSA in short).
In this book, there is a Command Processor pattern, which is based on the Command Pattern in GoF book. The most important difference is the newly introduced CommandProcessor. In the original Command Pattern, it defines how to create Commands, and each Command has an execute and undo methods.
The Command Pattern is one of my favourite design patterns. It is also a good example that design patterns do change over time. In part I, we talk about the original version from the Design Patterns book. This pattern first appears in the famous GoF book, described as follows: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
If you are a programmer, especially backend programmer, sooner or later you will face the problem of storing users’ passwords. Even though at first sight this seems like an entry level problem that we should hand over to an intern, it is really not. If you ask me how to do it. My first answer would be DON’T DO IT! I’m serious, try to avoid it as much as you can, just use Google or Facebook signin and your life goes on.