

Library patterns: Multiple levels of abstraction - reinhardt1053
http://tomasp.net/blog/2015/library-layers/index.html

======
akkartik
This article gets at the crux of the difference between what I think of as the
OO and FP mindsets: OO mindset is overly zealous about applying
'encapsulation' and 'information hiding'. An OO enthusiast might say that
revealing your internals in this way is bad design, and if you need it you
should 'encapsulate' the 15% and 4% solutions in their own (Helper, ugh)
classes. The extreme-radical FP view is to ask why we need keywords like
_private_ at all. Why not just show functions that are easy to use and harder
to use, and let callers decide what works best for them.

As you can infer from my use of scare quotes, I side with the author on this
after accumulating repeated scar tissue.

~~~
tieTYT
> Why not just show functions that are easy to use and harder to use, and let
> callers decide what works best for them.

Won't you be stuck exposing those APIs for the lifetime of the product or risk
breaking backwards compatibility?

What if you could make the code significantly faster by changing the
parameters you pass in to an internal function? What if you discover a bug
that you can only change by changing a method's signature? What if you just
want to refactor? Doesn't exposing your internals prevent you from doing these
things?

(Note, haven't read the article yet).

~~~
jessaustin
_Won 't you be stuck exposing those APIs for the lifetime of the product or
risk breaking backwards compatibility?_

A real revelation for me over the last year of using nodejs more and more, is
that every component can use its own dependencies, at exactly the versions it
requires. So, when you add to an API, bump minor. When you take away, bump
major. Either way, you can bump patch for bug fixes, on any major-minor combo,
whenever you want. So "stuck" isn't really possible any more.

