Fork me on GitHub
#clojuredesign-podcast
<
2020-06-10
>
nate19:06:15

@drewverlee I totally agree, adding a layer of functions raises the bar, so it needs to pay for itself. In the episode, we were talking about a cohesive set of functions to operate on a "state", specifically the set of websockets that are currently connected. So the functions are not generic, they all take state as their first argument. These functions hide implementation details (allowing for growth, encapsulating logic), but they also serve as a list of all the valid operations. The state is just a Clojure map at the top, so there are an almost infinite number of changes that can be made with the core functions, but in the context of maintaining a set of websockets, the list of operations are finite (add socket, remove socket, update socket ping timestamp, etc). Giving these operations names (by making them functions) allows me to think at the domain level rather than the data manipulation level. Then, when I'm working on the functions, I can have all of the internal logic in my head, but when I'm working on another part of the application that only needs to manipulate the websocket data, my mind is freed from thinking about those details. Some functions may end up being just an assoc or filter, but usually they are more complex and the mental savings is higher.

3