http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism
On Wednesday, May 13, 2015 at 1:09:48 AM UTC-7, Juan A. Ruz @tangrammer wrote: > > Hi guys, > when you talk about encapsulation do you mean using defrecords + protocols > ? > In this case, we are talking of choosing defrecords instead of plain > functions. Maybe it would be better if we talk too about the drawbacks of > this choice. For example, can we compose or extend protocol functions (I > mean to extend existent component protocol functions). > > In some occasion, I wanted to use juxt/bolt [(formerly juxt/cylon) > security component based system] in GoogleAppEngine but juxt/bolt uses > http-kit and GAE dont' let you use this lib dependency. So at last I had to > fork juxt/bolt to switch the http client library for plain java.net > classes. So, I wonder myself which are the limits of reusability in > component pattern. > > > > > > > > > El viernes, 8 de mayo de 2015, 18:29:50 (UTC+2), Brian Craft escribió: >> >> 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.
