After having read Douglas Crockford’s book “Javascript: The Good Parts”, I had learned some ways to leverage objects and information hiding, in the following manner:
var fooInstance = function() {
var privateAlpha;
return {
getAlpha: function() {
return privateAlpha;
},
setAlpha: function(a) {
privateAlpha = a;
}
};
}();
fooInstance.setAlpha(10);
console.log(fooInstance.getAlpha()); //10
fooInstance.setAlpha(20);
console.log(fooInstance.getAlpha()); //20
However, if you do a quick search on StackOverflow, you’ll quickly encounter a huge number of answers on javascript questions which say not to bother with private variables. Their reasoning is “well, you can just look at the javascript source in the browser, so what’s the point?”. This is missing part of the point.
One of the primary points of encapsulation is to control the internal state of the object, by only providing a limited interface. This protects the integrity of the state.
BUT… the other purpose of private variables and encapsulation in any language is not simply security or protection from nefarious people. It’s abstraction. An external entity should not need or care to know how the internals are accomplished. The smaller the footprint of the interface, the less complexity exists for the consumer to understand. You should expose no more than is necessary to leverage the functionality. The result of doing so is code that has looser coupling and is easier to understand by those who wish to consume it.
Posted: November 19th, 2011 | Author: benlakey | Filed under: benlakey.com | Tags: abstraction, encapsulation, Javascript, software craftsmanship | No Comments »
A number of people have been asking me about the strange bits of code in my previous blog post, so I felt I should explain a bit.
The Javascript
The reason why this…
… gives you 53 is because javascript’s concatentation operator is the plus sign, and when it sees a string on the left operand, it forces the right operand to be promoted to a string, and then performs concatenation.
The precise opposite occurs when the operator is the minus sign.
The operator minus is the mathematical subtraction operator, and so when it looks at the operands, it promotes both sides to a numeric type, and performs the subtraction.
The Java
So why on earth does Java think this is OK ?
Integer foo = 1000;
Integer bar = 1000;
foo <= bar; // true
foo >= bar; // true
foo == bar; // false
This is because the act of doing the assignments at the top sets the underlying primitive int to be of value 1000, but the actual variables themselves are of type Integer, which is an object to wrap the int. Therefor, when you do a numeric comparison with either >= or <= it will use the primitive type underneath, whereas when you use the == operator, it tries to compare the objects, which are 2 different instantiations of Integer objects, and are therefor not equal.
Hope this helps.
Posted: December 15th, 2010 | Author: benlakey | Filed under: Uncategorized | Tags: Java, Javascript | No Comments »
Did you know that in JavaScript, if you do this:
You will get 53.
But yet if you do this:
You will get 2.
That’s what happens when you have a weakly typed language using ‘+’ for string concatentation. :)
Another oddity… In Java:
Integer foo = 1000;
Integer bar = 1000;
foo <= bar; // true
foo >= bar; // true
foo == bar; // false
I love these little language quirks. :)
Posted: December 6th, 2010 | Author: benlakey | Filed under: benlakey.com | Tags: Java, Javascript, wtf | No Comments »