I still find patterns useful, I am glad I learned them and I am super glad that they are now named consistently thanks to those books. They also make it easier to think about structures. When you need undo and redo, knowing about command pattern made it easy. When I see word decorator or iterator in code I know exactly what it is.
It was useful and it is still useful if you work in object oriented language and problems that match it.
> When you need undo and redo, knowing about command pattern made it easy.
This is an example of a pattern that's only needed in C++-like languages. In a language which supports messages (first-class method calls), undo stacks come naturally.
Note C++ has first-class function calls (function pointers), but not methods. NSInvocation does it all.
Just create a new command pattern implementation that implements the pattern interface. Deploy the factory method pattern to return the correct concrete implementation based on programming language.
>When you need undo and redo, knowing about command pattern made it easy
Undo and redo are easy even if you don't know about "command pattern"s. Every computing problem can be solved using a virtualization layer, and that's all the command pattern is. It's not even a pattern, really... it's just the way computing works.
You couldn't get more hand-waivy and abstract than that.
Except maybe if you said "just write some code to take input and produce output, that's all you need".
Yeah, it's a "virtualization layer" (though the usual terminology is "abstraction layer"). But that doesn't explain the specific of how to implement a layer that does undo/redo. Caching is also a layer, but it's not undo/redo. So it's not like "any layer will do".
The command pattern does explain one way of achieving it.
I'm talking about actual virtualization. Reifying objects in memory. That's completely different from abstraction, and nothing like caching. It's a process that requires interpretation or translation, and not nearly as broad as "abstraction" is.
Of course it is pattern and of course patterns are largely the way computing works. It is even one of original patterns in that book. If it seems so ordinary to you, then it is more of success ot patterns then any kind of failure. Nowdays, you learn these ideas just by reading code here and there, they are so ubiguous and simple and standard. Back then, people complained they are complicated.
Everything in computing is just a way computing works. Functional programming is also just the way computing works and it still makes sense to study it's structures. And eventually someone will come up with names eventually everyone will "just know".
If everything is vurtualization layer, the I don't find the term particularly useful. Then it is just the same as saying "a thing".
I didn't say "everything is a virtualization layer". I said every problem could be solved with one, because it is a fundamental capability of computing. It's the same difference between implementing something in hardware vs software.
That is kind of academic theorising. It is like saying that every problem is solvable on turing machine - yeah true, but practically I won't do it and need different solution.
It was useful and it is still useful if you work in object oriented language and problems that match it.