Talk on the list about encapsulation usually comes back to some variation of "you don't need it when you have immutable data structures". But in the long term I'm finding the problem of working w/o encapsulation is not the danger of data being mutated under you. Rather, it's the danger of all the module boundaries blurring over time, leading to the big ball of mud: a very fragile code base where everything depends on everything else.
E.g. if you model your application with a plain data structure which you pass around to different modules, each concerned with a small part of that data structure, the tendency over time is for every module to become concerned with every part of that data structure. Then you have no separation, nothing is reusable, and the code is very fragile. How do you avoid this, practically? In OO it would be enforced with encapsulation, so the next developer (which might be me, six months later) trying to fix a bug, or add a feature, knows "Oh, I shouldn't peek in here: this module isn't supposed to depend on that piece of data". -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
