Closures for class/module privacy considered harmful

http://sidekicksrc.com/post/closures-for-classmodule-privacy-considered-harmful/

by campbellmorgan • 13 years ago

38 58 13 years ago

gcb03• 13 years ago

The article lay the testability issue, but offers no alternative... Since as far as i know there are none.

Also article is kinda crap as it fails to understand the reason they are truly necessary. But upvoting to generate discussion here.

philjackson2• 13 years ago

The reason what are truly necessary? Private methods? The author doesn't seem to think they're worth bothering with given the trade-offs. Out of interest what makes you think they're necessary?

ianstallings2• 13 years ago

The reason they are used is to specifically hide implementation details from a consuming class or chunk of code. The reason we do that is so the caller cannot make assumptions based on internal details so in the future we can modify it radically and not impact the caller. This is abstraction and it's OOP 101.

gcb03• 13 years ago

There are several systems that must run untrusted code. Such as advertisement.

We actually depend on real private methods.

just because what you do every day makes it useless, it's presumptuous to assume it's the same for everyone.

paultannenbaum• 13 years ago

Here is a link to an article that discusses one possible way to test private functions: http://philipwalton.com/articles/how-to-unit-test-private-fu...

He basically exposes them while in a dev environment, and then uses a build tool to make them actually private. I agree with weego's comment though, its something that isn't usually worth the tradeoffs, as long as your team has discipline.

icarus127• 13 years ago

The argument seems to be "you shouldn't do this because it accomplishes the goal it was intended to". Saying don't use this pattern to hide internals because it achieves the goal of hiding internals seems dubious at best.

plorkyeran• 13 years ago

That would be why bulk of the article is about how you shouldn't actually want to completely hide your internals, and it's not a completely terrible argument.

It does ignore the other benefit of module-closures, though (avoiding namespace collisions). Explicitly exposing your "private" functions (prefixed with _) in the module object would be a better way of achieving what the author wants.

apalmer• 13 years ago

I had the same impression, basically the core arguments presented in the article really were a rejection of OOP information hiding, not really the specific technical implementation of using closures for information hiding.

weego• 13 years ago

Considered harmful is a little excessive considering his analysis is that it's hard to test. Hard to read is very subjective (I find no issues with it).

As for extension, it's a pattern that is useful in some circumstances. It's not really something you would chose to use if you needed extension. I was going to say it was like saying a Singleton is harmful if you then change your mind later and decide you want multiple instances but I'm pretty sure I risk being called out for hyperbole.

Generally though I find the notion of struggling to wedge privacy into JS code a waste of effort, there are much cleaner patterns. You are always relying on personal/group discipline and good habits when coding with JS anyway so why start by disadvantaging yourself.

AdrianRossouw• 13 years ago

i really wish there was a good alternative to this, because I sometimes find myself wanting to write tests for some of my private functions, which just don't really have any need to be exported.

*edit : i should add i have been making use of the fact that a lot of my modules are event emitters to work around this. so even if i don't expose the function as such, i trigger the event rather than use the function directly.

VBprogrammer• 13 years ago

I've heard it said in Java that if your private methods need testing its a sign that those methods should be public methods of another class.

I can't see why this would not also apply to Javascript, other than that Javascript is rarely written in a very pure "OO" way.

For what its worth I find _private methods to be a horrible hack, I'd much rather have true private methods and force the next developer to think about whether they truly want to make that method public in the hope they'd consider restructuring it.

barrkel2• 13 years ago

If your testing requires you to change your public API - especially, making its scope larger and more complex - the problem is not with your API, it's with your testing tools.

(Yes, this is a deficiency in Java amongst other languages. You don't want to be e.g. wading through the lower details of font kerning when trying to use an edit box widget, even when those sub-components need individual testing.)

efdee• 13 years ago

I don't think anything he said means changing the public API. Moving the methods to another class and making them public there does not mean the other class has to be visible to people using the API.

lmm3• 13 years ago

Most of the value of testing comes from giving yourself a use case for the APIs you're building, forcing you to think about what the interface should be in a real way. The actual testing of behaviour is almost a side effect.

(It's certainly not a tooling deficiency as there are tools that allow testing private methods in Java. IME the best developers make an explicit choice not to use them)

btilly• 13 years ago

Meh. The testing issue is easy to handle.

Just create a second entry point that exports everything you might want to test. "Secure it" (there is no real security here) to be only callable if a read-only global flag was set when the object was created.

In your private unit tests you set that flag, create the object, and get access to privates. In your normal code, there is no way to access those functions.

Yes, it is a hack. But I firmly believe that it is acceptable to have hacks to enable unit testing.

Whether or not any type of privacy enforcement is a good idea is a debate that I leave to others.

abecedarius• 13 years ago

Or another way without the global:

    function myModuleReally() {
        return [useMe, testMe];
    }
    function myModule() { return myModuleReally()[0]; }

It'd be nice if the programming environment gave us a "can opener" (not globally available) to open up closures we've made -- like http://gbracha.blogspot.com/2012/07/seeking-closure-in-mirro... -- but we can do plenty without it.

thaumaturgy• 13 years ago

A slightly better reason: creating closures is (comparatively) slow. I recently switched from a closure model to a prototype model in my main js lib; a quick series of tests in Chromium gave me a 13% speed increase in my core functions using the prototype approach.

This roughly matches what I read elsewhere, e.g. http://macwright.org/2013/01/22/javascript-module-pattern-me...

convergejd2• 13 years ago

If you need extension, you wouldn't use this pattern.

If you need to avoid this technique entirely because you're so frequently needing to unit test private methods, you have a design problem, not a testing problem.

Readability is subjective. Personally I tend to find this style a bit more readable than trying to use a naming convention to indicate privacy, as suggested later in the article.

Tooling -- any real world examples of this? It seems to me tooling would only need to worry about the public interface, not the private details.

"True privacy is a bad idea in OO" - You didn't limit this statement to javascript, so I just want to say this is ludicrous. Access control is an extremely valuable tool when you're building a large system where development may be spread amongst many teams. If you just meant client side JS, I would say your statement is debatable.

When you utilize true privacy, you're taking a very disciplined approach to building software. You prevent monkey patching or tinkering with the internal state from components who should not be concerned with that object's internal state. When you need changes, it forces you to think about how your changes impact the overall structure of your application, and whether you need to restructure aspects of your application in response to those changes. Without true privacy, sure, you could just patch some "private" method and move on with your life. As you utilize this technique more and more, however, and your application grows, it has the potential to turn into a big headache.

esailija4• 13 years ago

There isn't true privacy by default in Java or C# so how can they get by? Are they relying on the fact that programmers won't use reflection to access private? Does the client run the program with security manager on? What if the application cannot afford to run with security manager on?

convergejd2• 13 years ago

I don't disagree with anything you said, which makes me think I worded my response incorrectly. I was using the author's term "true privacy", but what I meant is traditional privacy that, when not explicitly attempting to circumvent it, will generate some negative action, such as a warning or a compilation error. My problem was the author's blanket assertion that this type of privacy is bad and should be avoided, even if it is available.

subtenante3• 13 years ago

It's not very proper to call these closures, is it? Their purpose is not to close around external variables available in the lexical scope.

And I'm ready to upvote the first blog post entitled "the 'considered harmful' meme considered harmful".

shmageggy2• 13 years ago

They look like closures to me. In javascript, functions are first class entities, so when he writes

  function privateFunction() {
  }

that is sugar meaning there is a variable named privateFunction and it points to a function. So the object that is eventually returned closes around these external variables.

subtenante3• 13 years ago

But if they're really closures, how can we explain such behaviour?:

http://jsfiddle.net/9uqZg/

serichsen• 13 years ago

Come on, "considered harmful" is really overused now. I usually do not even read articles with "considered harmful" in the title anymore, because it is usually someone whining about a thing he has not properly understood.

solox3• 13 years ago

Overused now? It was overused 11 years ago, and it still is.

http://meyerweb.com/eric/comment/chech.html

beat• 13 years ago

"Considered harmful" consider harmful, then?

krosaen• 13 years ago

Can't you expose the internal methods individually via the module for testing purposes without making them vulnerable to manipulation as they are used by the public methods?

Just tried this in the developer console:

    // module 'm' exposes 'p' that uses 'f' internally. Exposes
    // 'f' for testing purposes.
    var m = (function() { var f = function() { return 'a'; }; var p = function() { return f(); }; return {'p': p, 'internalF': f};})();

    m.p();
    // 'a'

    m.internalF();
    // 'a'

    m.internalF = function() { return 'haxor';};
    m.internalF();
    // 'haxor'

    m.p();
    // 'a'

oakaz• 13 years ago

and what year was this article written?

alptrv5• 13 years ago

I always wanted to know why would anyone want to hide their code at all? If you making a library you would never know how people going to use it. Why don't expose public interface using naming conventions and let the people freedom to break it when they really want to. I sometimes found myself using methods and variables that intended to be private because I wouldn't achieve needed functionality without touching them. Just imagine what if Backbone had all model's attributes private - that practically means that you wouldn't be able to extend a model or to inspect the model's attributes in the console. Of course you can say that adequate programmer would never do that, but that's exactly my point - you have to rely on programmer's ability to write decent code, while if everything was public you would also rely on your ability to hack things, yes this can be messy and you can shoot your leg, we all know that, but we all grown ups and we know what we are doing.

When I read about symbols in upcoming ES6 I can't get rid off the sense of anxiety because I fear thing would get worse, the only hope is that browser vendors would implement some means to inspect private state of the objects that use Symbols.

By the way, this was one of the reasons why Guido van Rossum had chosen not to add private state in Python: https://plus.google.com/115212051037621986145/posts/7wpbQTPR...

pessimizer• 13 years ago

Because you'll lose the ability to refactor the internal structure of the library without breaking people's code.

alptrv5• 13 years ago

Well if they use your private members thats all in theirs responsibility. What if they just want to make the thing work, ship the product, whatever else, and don't care about new versions.

ghostdiver2• 13 years ago

think about Google Analytics tracking script

lmm3• 13 years ago

If your language allows you to encapsulate state properly even within an inheritance hierarchy then that makes it a lot more possible to let users upgrade safely. Anyone who's had to upgrade a large codebase using Rails or Django knows how much trouble it can be; contrast that with upgrading Wicket which is a wonderfully smooth experience.

ianstallings2• 13 years ago

This article is myopically targeted at js. Hiding implementation details behind abstraction is a staple of good programming. It helps to decouple classes so you don't have to rewrite your calling code when the internals of the called class are changed.

davexunit• 13 years ago

The author mentions SICP, but apparently fails to remember the numerous instances where the SICP authors use closures to hide implementation details. I remain unconvinced that exposing implementation details for the sake of testability is a good thing.

ww5203• 13 years ago

"Considered harmful" is the code word for passive-aggressively manipulating an opinion as truth. Whenever I see it, I would mentally say, fuck you, just state your opinion as opinion and don't try to twist it around.

Back to the blog. Contrast to the claim, closure for class/module privacy is great because it separates inner implementation from public interface. I really don't want any outside code to touch the private code. Because tomorrow I might change the inner implementation, function signature, break the function into two pieces, or proxy-call other libraries. And I want the assurance that the change won't break any calling codes.

Public function is like global variable. Anyone can access it anywhere and anytime. You don't know how, where, and when people call it. If you change its signature, you pretty much have to hunt down every call of it to retrofit. Private codes have no such issue. It's best to limit the scope of codes that are intended to be private.

Testing private code is a non-issue. Nobody outside cares about your private functions. They care about your public functions serving as the public interface. You test your public functions as your users would call them. Your public functions in turn exercise the private functions.

If you really want to test the private functions, write private tests in the same scope as the private functions to call them.

PuerkitoBio• 13 years ago

This. And if you want to extend, encapsulate.

alptrv5• 13 years ago

Why hide it completely? What about exposing your interface by convention like in Python? Never heard anyone suffering from inability to make methods and fields private in Python.

ww5203• 13 years ago

Because it's a hack in Python.

Edit: Why not make all variables global? Why not just use convention to label a globally scoped variable as "global" or as "local"? You can make it work as a convention. Now apply that to the whole language and to all the developers ever use it.

_greim_• 13 years ago

Why drag closure into this? Closure is just the ability for code executing in a function to see variables above its immediate scope (interesting/non-intuitive effects when combined with asynchronous logic notwithstanding). The thrust of the article is really about hiding data from access by external code. Closure just happens to be a mechanism JS devs typically exploit to accomplish that.

ghostdiver2• 13 years ago

Hint: use something like

  var DEV = true;

  (function() { 
     var priv = function() {};
     if(DEV) 
       this.priv = priv; 
   })();

and then use Closure Compiler with option: --define DEV=false

mkehrt• 13 years ago

Wait, so closures for encapsulation are bad because they allow encapsulation? You're complaining that you can't get access to private member functions this way? Isn't that what encapsulation is for??

pornel• 13 years ago

You cannot know ahead of time how someone else will want to modify your code

And this is exactly why I make implementation private. Otherwise my implementation becomes my public interface and I can't change it without breaking somebody else's patch.

If you’ve got a tricky interaction between a few private functions it’s very helpful to be able to test them!

Then refactor those tricky functions into another class with testable interface.

    var SomeModule = (function(trickyFunctionality) {

      function publicFunction() {
        trickyFunctionality.doTheTrick()
      }

      return {
        publicFunction: publicFunction
      }

    })(new Tricky())

16bytes• 13 years ago

Every so often I hear about a frustrated programmer complain about not being able to access private or otherwise inaccessible methods.

Could that code be useful? Sure, but that's not the point.

Information hiding is one of the core concepts in OOP:

http://en.wikipedia.org/wiki/Information_hiding

It's not even constrained to OOP, take C for instance: why it is that all functions are not exported in a shared library? Are they nefariously hiding code they don't want you to see? No, it's just that they are minimizing the interface between components, which is a concept as old as modular programming itself.

It makes change easier to contain and allows one to reason over large systems.

This is a good thing. Hiding implementation details is a good thing. Using closures to implement private functions in javascript is not bad. It's advocated in "Javascript, the good parts", as a pattern.

Should one try and write javascript as if it were java? No, and overuse of this pattern leads to a bunch of boiler plate. One usually tries to remain state-less and write deterministic, side-effect free functions that do not depend on closed variables.

Is it handy tool in some cases to implement DRY? Yes. Should it be considered harmful? No.

gruseom• 13 years ago

The article is considerably better than the comments here imply. In my view, the OP is showing intelligent intuition about software.

I've encountered the exact same issues that they have. It's frustrating when code wrapped up in a function prevents you from testing or experimenting in a REPL. It's infuriating when a framework wraps your code in one of these mega-lambdas so you can't get at it. There are many programming techniques that require the ability to breach encapsulation when appropriate.

Meanwhile, the virtues of enforced privacy are overrated. There are countless ways to screw up software; trying to lock things down so the next guy can't screw them up (preventing access, etc.) is a classic mistake. Modularity is extremely important in systems design, but not as an enforcement mechanism. It's an organizational tool. It's about decomposition and factoring, not hiding things so that only you can control them.

It's worth noting that Smalltalk doesn't have private methods [1], and that this was regarded as a feature not a bug. That alone shows that there's no particular link between enforced-privacy and OO, or even enforced-privacy and encapsulation.

To some extent this is a matter of taste, but I come down on the side that sees little value (and considerable drawbacks) in the privacy fetish. It's one of those things that people believe in because it sounds like things ought to work that way, when in reality they do not.

[1] http://stackoverflow.com/questions/7399340/smalltalk-public-...

esailija4• 13 years ago

Enforced privacy is not as common as people think either, so you don't really even need to pull out the Smalltalk argument. In Java, C#, PHP etc it is not possible for the developer to actually enforce privacy like you can in JS because the privates are readily accessible through reflection if needed.

Another point is that the Javascript enforced privacy pattern only supports private, so 2 internal classes cannot get at each other even if they are maintained together as a package. That encourages creating god objects which is not surprisingly what I commonly see in projects that use enforced privacy in Javascript.

Closures for class/module privacy considered harmful

Related Stories