If your modules are becoming big and unwieldy, you can also take a step toward (conceptual) OO and have your modules be separate entities that communicate through message passing (i.e. objects, although probably closer to Erlang's processes than Java objects). Messages are the key missing piece of many OO languages; Clojure maps are really nice for that. You can use core.async to establish communications between your modules, and defining the interfaces becomes akin to defining a network protocol (though with richly structured messages).
This way, each module is only exposed to what other modules send it, your code is well decoupled and isolated, and when it keeps growing and it makes sense to separate the code base into different processes, the refactoring is, if not trivial, manageable. Disclaimer: this is just an idea, I have not had the opportunity to actually try it out on a real, reasonably complex codebase. On Monday, 11 May 2015, Frank Castellucci <frankiec...@gmail.com> wrote: > 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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');>. > For more options, visit https://groups.google.com/d/optout. > -- 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.
