Hacker News Reader

Author is on the verge of having a Clojure epiphany.

> 1. You should often be using different objects in different contexts.

This is because "data" are just "facts" that your application has observed. Different facts are relevant in different circumstances. The User class in my application may be very similar to the User class in your application, they may even have identical "login" implementations, but neither captures the "essence" of a "User", because the set of facts one could observe about Users is unbounded, and combinatorially explosive. This holds for subsets of facts as well. Maybe our login method only cares about a User's email address and password, but to support all the other stuff in our app, we have to either: 1. Pass along every piece of data and behavior the entire app specifies 2. Create another data object that captures only the facts that login cares about (e.g. a LoginPayload object, or a LoginUser object, Credential object, etc.)

Option 1 is a nightmare because refactoring requires taking into consideration ALL usages of the object, regardless of whether or not the changes are relevant to the caller. Option 2 sucks because your Object hierarchy is combinatorial on the number of distinct _callers_. That's why it is so hard to refactor large systems programmed in this style.

> 3. The classes get huge and painful.

The author observed the combinatorial explosion of facts!

If you have a rich information landscape that is relevant to your application, you are going to have a bad time if you try modeling it with Data Objects. Full stop.

See Rich Hickey's talks, but in particular this section about the shortcomings of data objects compared to plain data structures (maps in this case).

https://www.youtube.com/watch?v=aSEQfqNYNAc

View on HN

(defrecord UserLoginView [email password]) ;; DIFFERENCE: compile-time validation (defn login [^UserLoginView view] (authenticate (:email view) (:password view))) ;; Usage (let [user-data {:user/email "user@example.com" :user/password-hash "hash123" :user/address "123 Main St" :user/purchase-history []} ;; DIFFERENCE: construct the intermediary data structure - ignore extra stuff explicitly login-view (->UserLoginView (:user/email user-data) (:user/password-hash user-data))] (login login-view))

(require '[clojure.spec.alpha :as s]) (require '[clojure.spec.gen.alpha :as gen]) (s/def :user.login/email string?) (s/def :user.login/password-hash string?) (s/def :user.login/credentials (s/keys :req [:user.login/email ;; spec's compose :user.login/password-hash])) (defn login [credentials] ;; DIFFERENCE: runtime validation {:pre [(s/valid? :user.login/credentials credentials)]} (authenticate (:user.login/email credentials) (:user.login/password-hash credentials))) (let [user-data {:user.login/email "user@example.com" :user.login/password-hash "hash123" :user/address "123 Main St" :user/purchase-history []}] ;; DIFFERENCE: extra data ignored implicitly (login user-data)) ;; Can also pass a minimal map (login {:user.login/email "user@example.com" :user.login/password-hash "hash123"}) ;; or you can generate the data (only possible because spec is a runtime construct) (let [user-data (gen/generate (s/gen :user.login/credentials)) ; evaluates to #:user.login{:email "cWC1t3", :password-hash "Ok85cHMP5Bhrd4Lzx"} ] (login user-data))

You say "it makes sense to unit test logins using every conceivable variation of `UserLoginView`", well, with spec you can actually *do that*: (require '[clojure.test.check.properties :as prop]) (require '[clojure.test.check.clojure-test :refer [defspec]]) (defspec login-always-returns-session 100 (prop/for-all [creds (s/gen :user.login/credentials)] (let [result (login creds)] (s/valid? :user.session/token result)))) This is impossible with Records/Objects - you can't generate arbitrary Record instances without custom generators.