A clojure enthusiast here, with quite a bit of OO experience so far. I find the section about template method to make no sense at all. Having parallel implementations of all intended operations (get-account, save-account) for all possible backends (db, datomic, http-server), and scattering them around creates the very problem of unmaintenable spaghetti code that the OO mechanisms try to address in the first place. What if someone supplies mismatching methods e.g. get-account-from-db and then save-account-to-http-server? what if they need some internal state to determine how to call the underlying backends? Worse, what if they have data mapping for the backend, or create/add different metadata in the process of doing get and then save/update it during save phase? OO allows you to organize everything in the context. Specifically in this case, I see value in creating three different AccountBackends for managing each of db, datomic and http-server - each subcribing to an interface that says you need to define how you 'get' and how your 'save'. When it comes to enterprise scale software, it's not about "that's it; strategy-pattern/template-method-pattern in 20 odd lines!". It's more about organizing code, components, domain/business logic in a structure that's easier to reload into a mental model - may that be when someone new joins the team, or when you have to root-cause a pressing issue in the code that someone else wrote. Fighting the ecosystem is the last thing you want in such situations. I wish and hope clojure has other, better semantics that allow better organization of related code/methods, than this.
I think the idea is just show how easy some GoF patterns are when you have first class functions, in this case, in clojure. If you ask me, you can write good software in both FF or OO programming; I think both paradigms trying to resolve different things.
I cover my interpretation of the GOF design patterns in clojure on my blog. drewverlee.github.io/tags-output/Design%20Pattern/. I haven't gotten to the visitor pattern yet but you i'm guessing we should perfer runtime polymorphism over a conditional.
