Javascript Closure Style Similar to Java Class Structure

Question

PROBLEM: There is a coding imperative (S. McConnel, Code Complete) that one shouldn't code on language, but by means of it, e.g. doing right style things even if language doesn't have some possibilities. Javascript is a script language in its heart, but it pretends being OOP very much. I want my Javascript and Java coding styles be better agreed on that basis.

QUESTION ONE: In Javascript methods I split code for simplicity and do encapsulation using closures. One large method turns into multiple inside its scope. Is it a bad practice?

QUESTION TWO: In Javascript method I declare variables first, then declare a method-constructor with a name of its parent-method, then go other methods-resources - like in Java classes. No script is floating directly in the body, except for one-line constructor call in the end of parent-method (void or return). When you open a closure method its main operations are atop. Any reasons why shouldn't I do that?

function parentFunction() {
 var myVariable;
 var scope = this; // Keep scope stable inside enclosed methods.
 function parentFunction() {
 // A pointless action to demonstrate an approach:
 return (
 sonFunction() ||
 daughterFunction());
 }
 function sonFunction() {
 return scope.name;
 }
 function daughterFunction() {
 return scope.name;
 }
 return parentFunction(); 
}

• gnat: related: How to mix different styles of programming on several languages?
• gaussblurinc: @Zon, I think that your example seems similar to Perl closures and Perl oop implementation. Closer look here
• Robert Harvey: It seems that you've created a false dilemma. Should you follow good style, whenever possible? Of course. Does that mean you should avoid certain javascript practices because they "emulate OOP?" No, it doesn't. You use methods inside methods and closures because they provide encapsulation, not because they emulate OOP.
• Zon: Well, besides encapsulation, it turns to advantages of artificial constructor structure, then. The main reason I try to do it - is to see the core of the method when I start scrolling it. I don't want to have it lost after function bodies. But it results in a "method called before defined" style error (in JSLint, for example). So not just because OOP does it.

Answer 1

Where this style starts to be a little awkward is when you introduce public methods:

function ParentFunction() {
 var myVariable;
 var scope = this; // Keep scope stable inside enclosed methods.
 function parentFunction() {
 sonFunction(); // no 'this'/'scope'
 this.daughterFunction(); // needs 'this'/'scope'
 }
 function sonFunction() {
 return scope.name;
 }
 scope.daughterFunction = function() {
 return scope.name;
 };
 return parentFunction(); 
}

Or define public methods like this, avoids "sometimes use this/scope, sometimes not":

function daughterFunction () {
 return scope.name;
}
scope.daughterFunction = daughterFunction;

But that's even more boilerplate. My advice is: Go with the language. There is no privacy, there is no classes (yet). But a pretty powerful prototype system:

function ParentFunction() {
 // ...
}
ParentFunction.prototype = {
 sonFunction: function () {
 return this.name;
 },
 daughterFunction: function() {
 return this.name;
 }
};

Which is very much like Java classes

class ParentFunction {
 public ParentFunction() {
 // ...
 }
 public string sonFunction() {
 return this.name;
 }
 // ...
}

Or (near future) JavaScript classes:

class ParentFunction {
 constructor() {
 // ...
 }
 sonFunction() {
 return this.name;
 }
 // ...
}

• Zon: Appreciate your answer. Calling scope for public methods is really a mess-up. On the other hand, it could be a meaningful variable which is clearer than dynamic this.
• Zon: Do you mean closure is evil in Javascript and one shouldn't use it for encapsulation? Actually Crockford talks much about privacy in Javascript, and IDEs like Netbeans idetify enclosured methods like private in Navigator window. I like your approach with classes, but the problem is more about methods and building an hierarchy of them. We use ExtJS framework and prototype system is already incorporated inside of its classes. I build this inside a classs already. Such an hierarchy helps splitting large methods into smaller and not mix all small ones together - link it to a header method.
• Zon: Also finally decided not to use pseudo-constructor function at the top and put head-method operations right to method body. It reduces trickiness at last. But still functions go after that and JSLint grumbles it's used before defined.