I find it's really the same as in any other language. Certainly if you don't have any clearly-defined boundaries at all, you'll get a big ball of mud.
Encapsulation is about code organization and self-discipline. Define module responsibilities and boundaries in your developer documentation. Make it clear that X is not supposed to depend on Y. Enforce those boundaries through code review and refactoring. Regularly review module definitions to make sure they match the real requirements of the system. I developed Component[1] to help with one aspect of this problem. One shared map defines the structure of the entire system, but each “module” is only exposed to the subset of the system it needs. Other approaches: With a shared map, namespaced keywords can be a hint that something is “private” to a particular module. Alternately, you could establish the convention that elements of a shared data structure should *only* be accessed via helper functions, and use public/private Vars to enforce which aspects of a data structure are meant to be “public” to other modules. –S [1]: https://github.com/stuartsierra/component On Friday, May 8, 2015 at 5:29:50 PM UTC+1, Brian Craft wrote: > > 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.
