All I can say is that when I write code in Clojure (with higher-order functions), I reorganize code fairly often in these sorts of ways without thinking about the "name" for it (e.g. dependency injection or inversion of control).
I'm less interested in what it is called in other languages (where it seems like you have to really 'work' at it). Instead, I just think about functions, namespaces, and good design; which to me comes down mostly to answering the question "What code is responsible for what functionality and why?"
This is not to fault an article like this, but I find it striking. It reminds me of the point you hear often (e.g. in Russ Olsen's book on Design Patterns in Ruby). Some languages (e.g. Ruby) make patterns (e.g. from Java) so easy that you don't have to think about the pattern any more.
I have a lot of sympathy for this way of thinking, especially given that so many of the Gang of Four patterns seem to be complicated ways to do higher-order functions.
That said, all languages have patterns and a shared vocabulary around concepts is essential to a profession. So I'd encourage you to become familiar with the nomenclature of the patterns in the idiom you are programming in.
Finally, the Dependency Inversion Principle is a principle, not a pattern and it is as applicable in clojure/lisp/et al as in Java. That is, instead of thinking of the problem from higher to lower in abstraction, the responsibilities should be organized around functionality and the abstraction of the dependency should live with the code that does the depending, not with the code that is depended upon.
I'm less interested in what it is called in other languages (where it seems like you have to really 'work' at it). Instead, I just think about functions, namespaces, and good design; which to me comes down mostly to answering the question "What code is responsible for what functionality and why?"
This is not to fault an article like this, but I find it striking. It reminds me of the point you hear often (e.g. in Russ Olsen's book on Design Patterns in Ruby). Some languages (e.g. Ruby) make patterns (e.g. from Java) so easy that you don't have to think about the pattern any more.