Javascript Encapsulation

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.

Complexity

“Computer programs are the most complex things that humans make. Programs are made up of a huge number of parts, expressed as functions, statements, and expressions that are arranged in sequences that must be virtually free of error. The runtime behavior has little resemblance to the program that implements it. Software is usually expected to be modified over the course of its productive life. The process of converting one correct program into a different correct program is extremely challenging.”

-Douglas Crockford

How do you measure programmer productivity?

How do you measure programmer productivity?

When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.

The Law of Demeter

Hello boys and girls, it’s been a while. Let’s talk about OO design.

Have you heard of the Law of Demeter? If you develop software, you should. You may actually be familiar with its concepts without actually knowing that it had a formal name. At it’s core, the Law of Demeter is the explicit capture of the intent of encapsulation. The rules are as follows.

A method FooMethod of a class Foo should only call the methods of these:

• Foo
• An object created by FooMethod
• An object passed as an argument to FooMethod
• An object reference held as an instance variable of Foo

Uncle Bob summarizes it nicely: “In other words, talk to friends, not to strangers.”

This all sounds dandy and obvious, but it’s easy to forget and slip up when dealing with complicated designs, or designs that are poorly understood.

Happy coding.

Not the Last Programming Language

Uncle Bob Martin is a well respected figure in the software development industry, and the chief driving force behind the Software Craftsmanship movement. His talks on methodologies, languages, and the state of our industry are always entertaining and insightful. Uncle Bob tends to make a lot of analogies to other professions as a means to bring our industry to maturity, such as doctors, lawyers, etc. There are a lot of very valuable analogies to make there; Here’s some of what he has to say on the topic:

“Do you think the only time musicians play their instruments is when they are on stage? Do you think the only time that batters hit balls is during games? Do you think the only time lawyers give a closing is at trial? Of course not. These people are professionals; and professionals practice! Professionals study the minutia of their disciplines. Professionals know all the little tricks and quirks. They know the history, the theories, the anecdotes. They know techniques and methods. They know good options and bad options and how to tell them apart. And they know all this stuff because they practice, practice practice.” [source]

We as a profession must agree to a set of disciplines, a set of rules that we will follow. Doctors always wash their hands rigorously before doing anything, and if they didn’t, we would not consider them to be a ‘professional’. During an operation a doctor follows his discipline, does not allow fear to take over in the shadow of a deadline, and follows his rules step by step, carefully adhering to his disciplines. To this point in the history of software development, we have not technically had a ‘profession’ in the truest sense of the word. As Bob Martin tends to say in his talks, to this point we’ve operated a lot like this:

“All we knew about what programmers did was that for weeks/months we threw meat in the room, and later code came out.”

In the past several weeks however, he has made another observation which I find myself disagreeing with. He postulates that we may have reached the point in our industry where there are no more programming language paradigms to explore. His analogy to other professions this time around, is that of notation. Electronics, Chemistry, Biology, Mathematics, etc have agreed on common notations, and therefor so should we. I have to disagree with this. In those professions, the purpose of notation is purely communicating the ideas. Source code is not purely about the communication of ideas (although that is a large part of it). I think a better analogy here is that source code is like a wood craftsman’s tools. You don’t use the same tool for all jobs (unless you enjoy cutting large pieces of wood in half with your chisel). In software development, source code is your tool, and you must use the right tool for the job, and evidence of this is widespread. It doesn’t make sense to code up a thick C++ application just to parse logs, so you choose perl. It doesn’t make sense to create a GUI application in PHP, Basic, or Fortran, so instead you choose C#, Java, or Python.

I’d love you hear your thoughts on this, so leave a comment.