• Embracing Language Features: I believe it is essential to discard the notion that certain techniques are hacks. Utilizing core features of a language, such as closures, to abstract the details of objects is not considered hacking.

  It's crucial to understand that when employing private in class-based languages, you are essentially implementing a higher-level concept of concealing object implementation details. Rather than trying to replicate a private modifier in JavaScript, the focus should be on conceptual implementation, which may vary based on the tool/language being used.

  Coming from a C# background, I initially struggled to break free from the "hack" mindset when transitioning to JavaScript. However, once I grasped the power of closures, object literals, constructor functions, and callback functions, I began to appreciate JavaScript and create efficient code that leveraged its strengths.

• To conceal "private" functions, options include enclosing them within a namespace, initializing them as variables using the Module Pattern, or utilizing other variations of this pattern, which I personally prefer. While these variables may be recreated with each new instance, this behavior mirrors that of private variables in class-based languages. To mimic static behavior, one can assign values like MyClass.StaticVariable = "myStaticVariable."

• The ability to hide details in a dynamic language raises questions about the significance when public APIs can easily be altered. Viewing JavaScript through the lens of class-based languages overlooks the benefits of its dynamic nature. With JavaScript's versatility, tools like the Sinon library can seamlessly mock various functionalities by manipulating public APIs. This flexibility would be challenging to achieve in non-dynamic languages, showcasing the advantages of JavaScript's dynamic capabilities.

  Hiding implementation details aligns with good design principles for reusability and maintenance. Moreover, adhering to common patterns, such as encapsulation and Module Pattern in JavaScript, enhances communication within teams and fosters consistency across codebases, aiding future readability and understanding.

• In terms of readability, adhering to conventions and patterns improves code comprehension for readers. While applying similar practices in languages like C++ could potentially impact readability negatively, following established patterns in JavaScript enhances clarity and maintains consistency within a codebase.

• Utilize Conventions: Following conventions, such as prefixing variables with underscores, promotes clarity and consistency in codebases, even if the variables are accessible. The convention is widely used in libraries like jQuery UI and contributes significantly to code organization and readability.

Lastly, while advocating for doing things "the JavaScript way," it's important to recognize that there may be multiple approaches within the JavaScript ecosystem. Embracing this diversity reflects the excitement and beauty of working with JavaScript.

It's a misconception to think that languages like Java, C#, and others have strict privacy measures in place. In reality, access modifiers such as private serve more as guidelines for communication rather than strict enforcement.

Martin Fowler explains:

The purpose of access control is not to restrict access, but rather to indicate that the class prefers to keep certain aspects private. The use of access modifiers, like many concepts in programming, is primarily about conveying intentions through code.

This is where the underscore prefix comes into play - it signifies intention without fighting against the language's object model.

In Javascript, closures cannot be circumvented, unlike in other languages. However, this also limits functionalities such as:

• The ability to control properties' enumerability, writability, frozenness, sealedness, and extension
• Reflection through methods like getOwnPropertyNames and .keys()
• Inheritance and usage of the instanceof operator
• Generic methods that can operate on various types of receivers
• Potential future extensions of the object model

Essentially, using closures for OOP features only allows for grouping functions together, making it suitable for simple examples rather than complex scenarios requiring stricter privacy controls enforced by the system itself.

Additionally, creating unique function objects for each method per instance is necessary due to their observable identities.

When determining the preferred approach, it all comes down to your goals and objectives.

Alternative 1 involves reaching an agreement among developers regarding a specific naming convention. This method is ideal when you have a cohesive team willing to adhere to this agreement and they are the sole users of the software. As mentioned, this approach significantly enhances code readability and testability. It also ensures that there will be a larger pool of developers capable of understanding and maintaining the code compared to alternative 2.

On the other hand, alternative 2, which employs closures to create real private members of objects, is not considered a workaround but rather a fundamental aspect of how JavaScript operates. This approach is more suitable when there is a need to safeguard attributes within an object, particularly when sharing the code with external developers or making it publicly accessible. However, using this method may slightly compromise code readability and testability, while also limiting the number of developers who can effectively work with and maintain the code.

Furthermore, it appears there may be some misconceptions about JavaScript on your part. While JavaScript does lack direct support for private attributes, it also does not feature traditional "classes" or "class methods." Instead, everything in JavaScript revolves around objects, with the class constructor merely serving as a blueprint for creating an object, and methods being nothing more than object properties defined as functions. In essence, objects in JavaScript do not conform to the class-instance paradigm commonly found in other object-oriented languages.

As correctly noted, in JavaScript, once an object has been created, all its attributes—including function properties (methods)—can be modified, except those encapsulated within closures. While this flexibility underscores the versatility of JavaScript, it also poses challenges to protecting objects from unwanted alterations, something for which JavaScript is not explicitly designed (at least not yet). Although preventing users from tampering with your objects is unfeasible, leveraging closures can certainly increase the level of difficulty involved.

I trust that this information assists you in making an informed decision.

If you're looking for a powerful tool from the upcoming version of JavaScript, ES6, I highly recommend using WeakMap. I've successfully integrated it into IE8+ and have extensively written about its benefits.

function createStorage(creator){
  creator = creator || Object.create.bind(null, null, {});
  var map = new WeakMap;
  return function storage(o, v){
    if (1 in arguments) {
      map.set(o, v);
    } else {
      v = map.get(o);
      if (v == null) {
        v = creator(o);
        map.set(o, v);
      }
    }
    return v;
  };
}


var _ = createStorage(function(o){ return new Backing(o) });

function Backing(o){
  this.facade = o;
}
Backing.prototype.doesStuff = function(){
  return 'real value';
}

function Facade(){
  _(this);
}
Facade.prototype.doSomething = function doSomething(){
  return _(this).doesStuff();
}

For further details:

At my workplace, it is encouraged to follow the "namespacing pattern" and handle namespaces similarly to how you would in object-oriented programming languages.

To learn more about this concept, check out this insightful answer

In my opinion, utilizing private methods can be advantageous in restricting access to certain functions for other developers who may not have authority to use them.

For further insights on this topic, I recommend checking out Crockford's article, particularly focusing on the section pertaining to OOP and private members.

I hope you find this information helpful.

My go-to choice is the revealing module pattern. For more information, take a look here

While this may not directly answer the question of whether enforcing private methods is a good idea, it does suggest using closures as a way to achieve privacy in JavaScript.

The concept involves creating a closure within a constructor function, where private functions and variables can be declared without being accessible outside of the closure context:

// Utilizing a closure for private methods and variables
var MyConstructor = (function(){

    var private_function = function () {};
    var private_var = {};        

    return function () {

    }
})()

This approach has its pros and cons. It can prevent unintended modifications to objects in collaborative coding environments, but it also limits flexibility for future adaptations. Experienced programmers from a Perl background often advocate for more flexible code structures, while others prefer strict privacy enforcement for better code maintenance.

In practice, both approaches have their uses. The Perl community's CPAN repository showcases stable modules with varying levels of privacy, indicating that successful collaboration hinges on team respect for coding standards. Ultimately, the decision between lax or strict privacy rules depends on the team's dynamics and trust in future maintainers.

When faced with a problem, there are various approaches to consider based on factors like target browser support, project goals, and personal preference. I will shed light on some specific approaches that I find noteworthy.

Symbol Usage

The use of Symbols is gaining popularity as it offers a robust solution and is set to be a part of the upcoming ECMAScript standard. While currently achievable with a shim in ES5 compliant browsers, Symbol works well in most modern A-grade browsers except for IE 8. If compatibility with IE 8 is crucial, then this may not be the best option.

You can download the shim from: SymbolsForES5. This library allows you to start utilizing Symbols now, with seamless transition expected when Symbols become native in future browser versions.

Here's an example demonstrating the use of Symbols for private members:

var x = { };
var a = new Symbol();
x[a] = 5;
console.log(x[a]); // => 5

With access to the Symbol object 'a,' properties can be read from the 'x' object. However, those without access to 'a' cannot read it, enabling true privacy:

var Person = (function() {

    var firstName = new Symbol(),
        lastName = new Symbol();

    function Person(first, last) {
        this[firstName] = first;
        this[lastName] = last;
    }

    Person.prototype.getFullName = function() {
        return this[firstName] + ' ' + this[lastName];
    };

    return Person;

})();

var john = new Person('John', 'Smith');
john.getFullName(); // => 'John Smith'

Object.getOwnPropertyNames(john); // => [ ]

Using dontaccess Character

Prefixing a property with a character like underscore serves as a signal that it should not be accessed externally. Though still accessible, this method provides benefits such as efficient memory usage, full prototypal inheritance utilization, easy debugging, and broad browser compatibility.

This technique has been successfully employed, with an alternative symbol '#' used in the 'joi' framework developed by me:

function Person(first, last) {
    this['#firstName'] = first;
    this['#lastName'] = last;
}

Person.prototype.getFullName = function() {
    return this['#firstName'] + ' ' + this['#lastName'];
};

var john = new Person('John', 'Smith');
john.getFullName(); // => 'John Smith'

If Symbols do not align with requirements, this method has proven effective over time.

Private Members Inside Constructor

Despite concerns about memory/performance implications, using privates inside the constructor remains a viable option for achieving true privacy. While Symbols may not support legacy browsers, this model has been adopted in large-scale applications with no significant impact on performance. Optimizations for memory and performance are emerging, especially in modern browsers like V8/Chrome.

Though not my preference, experts advocate for this approach, citing its reliability based on successful implementations:

function Person(first, last) {
    this.getFullName = function() {
        return first + ' ' + last;
    };
}

var john = new Person('John', 'Smith');
john.getFullName(); // => 'John Smith'

Javascript engines can optimize this model by avoiding creating a new function for each getFullName method, improving efficiency.

Exploring WeakMaps

Consider exploring WeakMaps as an alternative if IE8 support is required while aiming to closely simulate private members within properties.