0

I'm relatively new to JavaScript and the whole pass by reference thing is a bit scary. Some of objects need to protect their data from being mutated externally. This is leading me to consider a design pattern where local member objects (simple value objects) are only accessible via getters that return only copies of the local object in order to prevent references from leaking.

Is this a standard practice? How is this normally handled?

Patrick
  • 827
  • 3
  • 14
  • 20
  • Possible duplicate of [Does JavaScript pass by reference?](http://stackoverflow.com/questions/13104494/does-javascript-pass-by-reference) – PM 77-1 Mar 03 '16 at 02:28
  • Yea I read that in the past, so my question is about what design patterns folks use to manage that. I figure everyone must use immutable libraries and copy constructors and getters – Patrick Mar 03 '16 at 02:32
  • @Patrick Read the linked duplicate question, then you can forget your worries. – Gerard Sexton Mar 03 '16 at 02:33
  • if the object needs protecting from bad code, i would suggest replacing the bad code. you could buy a really nice door lock, but for many reasons it's better to live in a safer neighborhood. i don't see how passing out copies helps either; if something is writing a change that does not stick, something else will be broken or at best, silently failing, which is not a big improvement and can actually make finding those sore spots harder. – dandavis Mar 03 '16 at 04:11
  • I'm surprised by everyone's responses. If you're exposing an api and want to protect the internals of it in the wild it seems like a standard pattern to protect the internals from rogue mutation. Heck, this is practically a page out of cornerstone java design patterns books. – Patrick Mar 03 '16 at 04:35

1 Answers1

0

It is not common, AFAIK. The more common pattern of information hiding is keeping private data in local variables within closures. For example:

var untamperableCounter = (function() {
  var counter = 0;
  return {
    next: function() {
      return ++counter;
    }
  }
})();

untamperableCounter.next();
// 1
untamperableCounter.next();
// 2
untamperableCounter.count
// ReferenceError
Amadan
  • 191,408
  • 23
  • 240
  • 301
  • Ok, but take that example and replace the primitive counter with an object. In that case you've just allowed your reference to the counter to leak. – Patrick Mar 03 '16 at 02:37
  • This is the same pattern of protecting state for concurrent programming that is presented in the java book "concurrency in practice" by tim periels – Patrick Mar 03 '16 at 02:39
  • Same thing. Who cares if they have the reference if there's nothing they can do with it? If all private state is in local variables, it is inaccessible. If you need to return an array, then sure, copy it; if you are returning a custom object, then that custom object can take care not to expose too much. – Amadan Mar 03 '16 at 02:39
  • If you return an object and then change a the state of that externally then everyone with a reference to that object will see the mutated state, right? – Patrick Mar 03 '16 at 02:42
  • Again: if you change the state, yes. But the point about closures is that it makes it impossible to change state in dangerous ways, as long as you hide anything sensitive. For example, `untamperableCounter`'s state is in `counter` variable, which cannot be accessed. – Amadan Mar 03 '16 at 02:43
  • It's not always clear what state mutations are safe when concurrent access is occurring. – Patrick Mar 03 '16 at 02:45
  • JavaScript does not have concurrent access, as it does not have threads; and WebWorkers can only interact by message-passing, which occur through JSON-serialised objects. This is not an issue. – Amadan Mar 03 '16 at 02:47
  • My point definitely applies in the react + flux framework. I guess I'm not able to explain. – Patrick Mar 03 '16 at 03:11