On May 13, 2015, at 11:07 PM, Brian Craft <craft.br...@gmail.com> wrote:
> http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism
>
> <http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)#As_information_hiding_mechanism>
In an environment where you can’t trust your co-workers(!), you certainly want
to hide *mutable* data so they can’t modify your objects’ state. When you
remove mutability, there’s a lot less damage they can do and they it’s really
more about which pieces of the system do you not want them to "use" (in terms
of functional APIs).
The "Clojure Way" seems to be "just make all functions public — they might be
useful to someone" although that then restricts what refactoring you can do in
future compared to exposing a smaller surface area. Since you can always call
private functions anyway (and access private data directly), you really need
conventions — and code review — to prevent abuse, and at that point having
foo.api and foo.impl namespaces — and a convention to not use foo.impl outside
of foo.api — is very reasonable and even automatically enforceable through
tooling.
When I first started doing Clojure (five years ago — yikes! feels like
yesterday!) I still had an OOP mindset around data hiding and I used defn- and
^:private a lot (well, ^{:private true} back then I guess). These days I tend
to make all my functions public and use namespaces if necessary to clearly
delineate APIs vs implementations. A def of immutable data tends to be public
too. It’s rare that I feel the need to make things private since immutability
means no one can "abuse" my data or my functions.
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
--
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.
