Brian One is better off thinking that avoidance, as per your note, is a *discipline* of *better practices. *As the architectural concepts of Separation of Concerns and Minimized Surface Areas were intended.
Many languages attempt to enforce this notion in something called encapsulation. However; Encapsulation is buzz as it is subject to the pressures of the moment, including but not limited to: 1. Market pressure for timely delivery - or "*Ef it, I'm just going to expose this one little thing for now...*" 2. Introspection - If I can find it, I'll figure out how to get/set it. Especially easy through such things as: 3. Byte Code Injection - In the case of Java, and, 4. Easy work arounds - In the case of Clojure's *(**def my-local #'ns/their-privates)* How to avoid it? Discipline and code reviews. Frank Castellucci On Friday, May 8, 2015 at 12:29:50 PM UTC-4, 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.
