Psst, over here! Want to learn a secret?

The concept of classical inheritance has stood the test of time as a reliable approach.

Implementing classical inheritance in JavaScript can be quite beneficial. Classes offer a great way to model objects and templates for structuring our world.

Classical inheritance is essentially a pattern. It's perfectly acceptable to use classical inheritance in JavaScript if it suits your specific requirements.

While prototypical inheritance emphasizes sharing functionality, there are instances where sharing a data scheme becomes essential, a challenge that prototypical inheritance fails to address adequately.

Are classes really as bad as people make them out to be?

No, they aren't. What the JavaScript community disapproves of is not the idea of classes per se, but rather sticking solely to classes for code reuse. Just as the language does not impose strong or static typing, it also doesn't enforce particular schemes on object structures.

In reality, underneath the surface, clever implementations of the language can transform ordinary objects into something resembling classical inheritance classes.

How do classes function in JavaScript?

All you really need is a constructor:

function getVehicle(engine){
    return { engine : engine };
}

var v = getVehicle("V6");
v.engine;//V6

Voila! We have a vehicle class without explicitly defining a Vehicle class using a special keyword. However, some individuals prefer the more traditional approach. For them, JavaScript provides (arguably) syntactic sugar by doing:

function Vehicle(engine){
     this.engine = engine;
}
var v = new Vehicle("V6");
v.engine;//V6

This accomplishes pretty much the same outcome as the previous example.

But what's still missing?

Inheritance and private members.

Did you know that basic subtyping is relatively easy in JavaScript?

JavaScript's interpretation of typing differs from that of other languages. So, what does being a subtype of a certain type entail in JS?

var a = {x:5};
var b = {x:3,y:3};

Is the type of b a subtype of the type of a? Let's say it follows the (strong) behavioral subtyping principle (the LSP):

<<<< Begin technical part

• Contravariance of method arguments in the subtype - Is fully preserved in this sort of inheritance.
• Covariance of return types in the subtype - Is fully preserved in this sort of inheritance.
• No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype. - Is fully preserved in this sort of inheritance.

Moreover,

• Preconditions cannot be strengthened in a subtype.
• Postconditions cannot be weakened in a subtype.
• Invariants of the supertype must be preserved in a subtype.
• The history rule

All these rules are at our discretion to uphold. We have the freedom to adhere to them strictly or loosely, but the choice is ours.

Therefore, as long as we follow these guidelines when implementing our inheritance, we are effectively applying strong behavioral subtyping, which is a potent form of subtyping (see note*).

>>>>> End technical part

Additionally, one can observe that structural subtyping remains valid.

How does this translate to our Car example?

function getCar(typeOfCar){
    var v = getVehicle("CarEngine");
    v.typeOfCar = typeOfCar;
    return v;
}
v = getCar("Honda");
v.typeOfCar;//Honda;
v.engine;//CarEngine

Not overly complex, right? And what about private members?

function getVehicle(engine){
    var secret = "Hello"
    return {
        engine : engine,
        getSecret : function() {
            return secret;
        }
    };
}

Here, secret functions as a closure variable, maintaining privacy similar to private variables in languages like Java but impervious to external access.

Can functions have privates too?

Excellent question!

To incorporate a private variable in a function shared on the prototype, one must first grasp how JS closures and functions operate.

Functions in JavaScript are treated as first-class entities, allowing them to be passed around.

function getPerson(name){
    var greeting = "Hello " + name;
    return {
        greet : function() {
            return greeting;
        }
    };
}

var a = getPerson("thomasc");
a.greet(); //Hello thomasc

As demonstrated above, you can pass the function bound to a to other objects, enabling loose coupling—a fantastic feature.

var b = a.greet;
b(); //Hello thomasc

Curious how b knows the person's name is "thomasc"? That's the magic of closures. Pretty neat, isn't it?

You might be concerned about performance. Let me reassure you about embracing the optimizing JIT.

In practice, duplicating functions like this isn't a significant concern. JavaScript excels in functionality! Closures present a fascinating concept; once understood and mastered, the benefits outweigh any minor performance impact. Rest assured, JS continues to improve its speed, negating such anxieties.

If this seems intricate, an alternative strategy involves mutual consent among developers regarding private variables—simple agreements dictating, "If my variable begins with _, please refrain from altering it." This would manifest as:

function getPerson(name){
    var greeter = {
        greet : function() {
            return "Hello" +greeter._name;
        }
    };
    greeter._name = name;
    return greeter;
}

Or adopting a classical approach:

function Person(name){
    this._name = name;
    this.greet = function(){
       return "Hello "+this._name;
    }
}

Alternatively, to cache the function on the prototype instead of reproducing copies:

function Person(name){
    this._name = name;
}
Person.prototype.greet =  function(){
       return "Hello "+this._name;
}

To summarize:

• Classical inheritance patterns can be advantageous for sharing specific data types

• Prototypical inheritance is equally powerful, especially for sharing functionality

• TheifMaster hit the nail on the head. The notion of keeping privates truly private isn't as crucial in JavaScript as many believe, provided your code establishes a clear interface. As consenting adults, we can navigate this aspect smoothly :)

_{*One might wonder: Were you attempting to deceive with the history rule? After all, property access lacks encapsulation.}

_{I confirm, no deception intended. Even without explicitly privatizing fields, adhering to a contract that avoids direct access suffices. Often, labeling variables with _ as suggested by TheifMaster establishes clarity. Moreover, I don't regard the history rule as critical in numerous scenarios, presuming property access treatment remains consistent. Ultimately, the power lies in our hands.}

Although you are a new member of StackOverflow, I need to be upfront and tell you that attempting to implement classical inheritance in JavaScript is not a good idea. It's important to understand that JavaScript is a prototypal object-oriented language, not a classical one.

Classical inheritance may seem appealing for those familiar with other programming languages, but it goes against the essence of JavaScript. Instead of trying to force traditional class structures onto JavaScript, embrace prototypal inheritance as it is more aligned with the language's nature.

In my early days as a JavaScript developer, even I tried creating libraries like Clockwork and augment for classical inheritance. However, I soon realized that this approach was hindering rather than enhancing my code. Classical inheritance introduces performance, readability, and maintainability issues that can be avoided by sticking to prototypal inheritance patterns.

For your benefit, I will provide two answers to your question - one demonstrating classical inheritance and the other focusing on prototypal inheritance, which I recommend exploring further.

Classical Inheritance in JavaScript

Many developers initially attempt classical inheritance in JavaScript, influenced by prominent figures like Douglas Crockford. Yet, it's essential to acknowledge that true prototypal inheritance offers more flexibility and efficiency in JavaScript development.

Your thirst for classes might stem from prior experiences, but understanding the power of prototypal inheritance is crucial. It's normal to stumble along the learning path, much like training wheels on a bicycle. While tools like jTypes exist to ease the transition, remember to shed these aids once you're confident in your prototypal skills.

Prototypal Inheritance in JavaScript

This section serves as a roadmap for when you're ready to delve into genuine prototypal inheritance. Dispelling misconceptions about needing classes or objects created from classes in JavaScript is pivotal.

ECMAScript Harmony classes serve as an example, illustrating how syntactic sugar disguises underlying prototypal concepts. Contrary to popular beliefs, dynamic object creation doesn't mandate class structures; prototypes suffice for efficient JavaScript coding.

Conclusion

Rather than fixating on classes and private states, leverage the existing strengths of JavaScript's prototypal inheritance. Functions encapsulate data adequately without resorting to convoluted class hierarchies.

If privacy concerns arise, simple naming conventions like prefixing variables with underscores can signal their intended restrictions. Embrace JavaScript's unique features, allowing your code to flourish without unnecessary complexities.

Alright, I've come up with a solution for this specific issue. In my approach, I emphasize following conventions by suggesting to prefix variables with _. My method involves keeping track of instances in an array and providing a _destroy function for removal. While there is room for improvement, you might find some inspiration from the following code snippet:

var MyClass = (function MyClassModule() {

  var privateVars = []; // an array holding objects of private variables

  function MyClass(value) {
    this._init();
    this._set('value', value);
  }

  MyClass.prototype = {

    // initialize instance
    _init: function() {
      this.instance = privateVars.length;
      privateVars.push({ instance: this.instance });
    },

    // access private variable
    _get: function(prop) {
      return privateVars[this.instance][prop];
    },

    // modify private variable
    _set: function(prop, value) {
      return privateVars[this.instance][prop] = value;
    },

    // delete private variables
    _destroy: function() {
      delete privateVars[this.instance];
    },

    getValue: function() {
      return this._get('value');
    }
  };

  return MyClass;
}());

var objA = new MyClass('apple');
var objB = new MyClass('banana');

console.log(objA.getValue()); //=> apple
console.log(objB.getValue()); //=> banana

objA._destroy();

console.log(objB.getValue()); //=> banana

During the execution, private and public properties do not need to be enforced as they are statically enforced. Projects with complex structures that require private properties to stay internal typically have a build or pre-process step in place for verification purposes. Even programming languages with syntax specifically for private/public access have methods to access private data at runtime.

The constructor+prototype method used for defining class-based objects is considered the simplest and most efficient approach. Implementing any additional complexities may result in decreased performance.

To avoid repeatedly typing ClassB.prototype., you can cache the prototype:

//You can omit the wrapper function in node.js
var ClassB = (function() {
    var method = ClassB.prototype;

    function ClassB( value ) {
        this._value = value;
    }

    method.getValue = function() {
        return this._value;
    };

    method.setValue = function( value ) {
        this._value = value;
    };

    return ClassB;
})();

This implementation does not rely on any external library and can easily be turned into a macro. Additionally, even a simple regex statement can be sufficient to verify the correct usage of "private" properties. Running

/([a-zA-Z$_-][a-zA-Z0-9$_-]*)\._.+/g

through the file will show that the first match is always this. Check it out here: http://jsfiddle.net/7gumy/

It may seem impossible without external influences affecting the value, but if it remains constant, you can protect it by encapsulating it within a function like this:

(function( context ) {

    'use strict';

    var SOME_CONSTANT = 'Hello World';

    var SomeObject = function() {};

    SomeObject.prototype.sayHello = function() {
        console.log(SOME_CONSTANT);
    };

    context.SomeObject = SomeObject;

})( this );

var someInstance = new SomeObject();
someInstance.sayHello();

To indicate that a property should not be modified, prefix it with an underscore like this._value instead of this.value.

Remember, you can create private functions by enclosing them within another function:

(function( context ) {

    'use strict';

    var SomeObject = function() {};

    var getMessage = function() {
        return 'Hello World';
    };

    SomeObject.prototype.sayHello = function() {
        console.log(getMessage());
    };

    context.SomeObject = SomeObject;

})( this );

var someInstance = new SomeObject();
someInstance.sayHello();

Check out this example demonstrating 2 'Classes' extending and interacting with each other: http://jsfiddle.net/TV3H3/

If you are interested in having private entities on a per instance basis, yet still want to inherit your methods, a potential set-up to achieve this could be:

var Bundle = (function(){
  var local = {}, constructor = function(){
    if ( this instanceof constructor ) {
      local[(this.id = constructor.id++)] = {
        data: 123
      };
    }
  };
  constructor.id = 0;
  constructor.prototype.exampleMethod = function(){
    return local[this.id].data;
  }
  return constructor;
})();

With the above setup, when you create a new Bundle, the value of data is securely stored internally:

var a = new Bundle(); console.log( a.exampleMethod() ); /// 123

This approach raises questions about whether having truly private values in JavaScript is necessary. It may be more beneficial for anyone needing to extend your code--including yourself--to have access to all parts of it.

There are drawbacks to the previously mentioned pattern, such as readability issues and difficulties accessing "private" values. One notable issue is that each instance of Bundle retains a reference to the local object. This means that if you were to create numerous Bundles and then remove all but one, the data in local would not be garbage collected for any Bundles created. Addressing this requires additional deconstruction code, adding complexity to the setup.

Considering these challenges, it might be advisable to reconsider the concept of private entities/properties in JavaScript, regardless of the chosen pattern. The versatility of JavaScript allows for various approaches, emphasizing its flexibility over the more rigid nature of class-based languages. While this versatility can lead to confusion, it also enables rapid and expressive development.

regarding the statement mentioned in your query:

In a vector drawing application, the workspace is typically empty when starting a new drawing. It may seem impossible to create a new "line" from an existing one. In general, situations where objects are dynamically created require the use of classes.

You might be mistaken in thinking that objects in Javascript can only be generated by duplicating existing objects. This would raise the question of how to create the very first object since there are no existing objects to clone.

However, it is indeed possible to create objects from scratch, using a simple syntax like var object = {}

Starting with the most basic form of object - an empty object. For more functionality, you can add properties and methods like this:

var object = {
  name: "Thing",
  value: 0,
  method: function() {
    return true;
  }
}

And just like that, you're ready to go!

While there may be individuals more skilled than I at addressing this query, I feel compelled to highlight a specific aspect that you recently modified - the inclusion of the private variable section.

To achieve this functionality, one can employ closures; a remarkable feature enabling a function to possess its own distinct environment. Consider the following approach:

var line = (function() {
  var length = 0;
  return {
    setLen : function (newLen) {
      length = newLen;
    },
    getLen : function () {
      return length;
    }
  };
}());

This code snippet will define 'line' as an object containing both the setLen and getLen methods, while preventing direct access to the variable length without utilizing these designated functions.