Polymorphism is a powerful feature. The purpose of polymorphism is to provide a single, consistent interface to a caller. There may be multiple ways to carry out that behavior, but the caller doesn’t need to know that. When you call a polymorphic function, you remain blissfully ignorant of (and therefore decoupled from) which method will actually run.
Don’t use polymorphism where it doesn’t exist.
All too often, I see protocols or multimethods used in cases where the caller does know which method is going to be called; where it is completely, 100% unambiguous, at every call site, which method will run.
As a contrived example, say we have this protocol with two record implementations:
(defprotocol Blerg (blerg [this])) (defrecord Foo  Blerg (blerg [this] ;; ... do Foo stuff ... )) (defrecord Bar  Blerg (blerg [this] ;; ... do Bar stuff ... ))
Then, elsewhere in the code, we have some uses of that protocol:
(defn process-foo [x] ;; ... (blerg x) ; I know x is always a Foo ;; ... )
(defn process-bar [x] ;; ... (blerg x) ; I know x is always a Bar ;; ... )
If you know which method will be called, it’s easy to fall into the trap of depending on that specific behavior. Now you’ve broken the abstraction barrier the protocol was meant to provide.
(defn process-bar [x] ;; ... (blerg x) ; I know x is always a Bar ;; ... do something that relies on ;; Bar's blerg having been called ... )
Code like this is already tightly coupled, which isn’t necessarily a problem. The problem is that the coupling is hidden behind the implied decoupling of a protocol. That’s going to lead to bugs sooner or later.
Instead, write ordinary functions with distinct names and let the caller use the appropriate one.
(defn blerg-foo [foo] ;; ... do foo stuff ... ) (defn blerg-bar [bar] ;; ... do bar stuff ... ) (defn process-foo [x] ;; ... (blerg-foo x) ;; ... ) (defn process-bar [x] ;; ... (blerg-bar x) ;; ... )
Remember the Liskov Substitution Principle: If you cannot substitute one implementation of a protocol for another, it’s not a good abstraction.
This post is part of my Clojure Do’s and Don’ts series.