I've been using the Ice Factory pattern for years and even taught it to hundreds students so I quite like it (at least in ES5).
However, I've taken the example of testing but there is other ones. Suppose that there's an object Foo with an internal state bar which is a variable scoped to the constructor. For some reason, you don't want to expose bar to the world, yet you want to have a Foo.hasSameState(otherFoo) method. Since you can't access the private member, you're kinda screwed.
In short, I don't really recommend to create private members using this pattern or if you do you need to be really careful because you might very easily end up refactoring code.
If I understand correctly, what you're getting at is that – unlike some other languages – JavaScript doesn't yet support the notion of semi-private members (e.g. "protected" in Java or "friend" in C++). So, using a private member when what we really need is a semi-private member, will get us into trouble.
I've been using the Ice Factory pattern for years and even taught it to hundreds students so I quite like it (at least in ES5).
However, I've taken the example of testing but there is other ones. Suppose that there's an object
Foowith an internal statebarwhich is a variable scoped to the constructor. For some reason, you don't want to exposebarto the world, yet you want to have aFoo.hasSameState(otherFoo)method. Since you can't access the private member, you're kinda screwed.In short, I don't really recommend to create private members using this pattern or if you do you need to be really careful because you might very easily end up refactoring code.
Thanks for the clarification.
If I understand correctly, what you're getting at is that – unlike some other languages – JavaScript doesn't yet support the notion of semi-private members (e.g. "protected" in Java or "friend" in C++). So, using a private member when what we really need is a semi-private member, will get us into trouble.
I definitely agree with that.
Yes exactly :)