Thanks, everyone, this has been very helpful. On Sunday, May 10, 2015 at 8:28:37 AM UTC-7, Stuart Sierra wrote: > > 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.
