We Keep Coding

Are classes necessary in Javascript? What effect do they have on creating objects?

Consider this example code:
class Test {
say() {
console.log("I'm a test.");
}
}
let TestFromClass = new Test();
let TestFromObject = {
say() {
console.log("I'm also a test.");
}
};
TestFromClass.say(); // Output: I'm a test.
TestFromObject.say(); // Output: I'm also a test.
I understand that it's possible to create objects, such as TestFromObject, without first creating a class with the class keyword. Is class necessary at all? Is there a difference between these two kinds of objects? If so, what effect does it have to use class explicitly?

Using new creates a new object whose internal prototype is the class's prototype. For example:
class Test {
say() {
console.log("I'm a test.");
}
}
let TestFromClass = new Test();
console.log(Object.getPrototypeOf(TestFromClass) === Test.prototype);
This is useful for creating multiple objects. The usual reason to do this is so that each object can have some sort of associated state - generally, the values of its properties. For example, a Person object might have a name and an age property.
However, if there is no data to associate with an instance (as with TestFromClass in the original code), there's not much point having an instance at all. The TestFromObject approach makes much more sense if the purpose is just to collect named functions into a data structure.
That said, it's sometimes desirable to have a class that has some functions associated with it (like say) which don't have anything to do with an instance of its data, while still being able to create an instance - perhaps using other methods on the prototype. This isn't that uncommon, and is done by making the non-instance-related functions static:
class Person {
static canEat() {
return ['apples', 'bananas', 'carrots'];
}
constructor(name, age) {
this.name = name;
this.age = age;
}
}
const p = new Person('Bob', 99);
console.log(p.name);
console.log(Person.canEat());

A class is more or less just syntactic sugar for a prototype:
// The class way
class Test {
say() {
console.log("I'm a test.");
}
}
// The old fashioned way
function Test() {
}
Test.prototype.say = function () {
console.log("I'm a test.");
};
The difference in both these cases with direct object creation is that the methods belong to the prototype, not directly to the object.
The code TestFromClass.say() must go through the prototype chain to find a say method, while TestFromObject directly has the method.
Other than that, there's no difference.

Is there a difference between these two kinds of objects? If so, what effect does it have to use class explicitly?
There effectively isn't a meaningful difference, but it does have some minor effects:
When you create an object with literal syntax, unless you use the special __proto__ property name, its prototype will always be Object.prototype. (Note that __proto__ is officially optional, a JavaScript engine doesn't have to provide it.) When you create it with new X, provided X is a constructor function created with class syntax, the result will have the prototype X.prototype.
Methods defined within an object literal are directly placed on the object. Methods within class X go on X.prototype (non-static ones) which the object inherits.

Objects come in two forms: the declarative (literal) form, and the constructed form.
The literal syntax for an object looks like this:
var myObj = {
key: value
// ...
};
The constructed form looks like this:
var myObj = new Object();
myObj.key = value;
The constructed form and the literal form result in exactly the same sort of object. The only difference really is that you can add one or more key/value pairs to the literal declaration, whereas with constructed-form objects, you must add the properties one-by-one.
Note: It's extremely uncommon to use the "constructed form" for creating objects as just shown. You would pretty much always want to use the literal syntax form. The same will be true of most of the built-in objects.
P.S. To read more in detail go to
https://github.com/getify/You-Dont-Know-JS/blob/2nd-ed/this-object-prototypes/ch3.md

So you created a class called Test which is the base class. The you added a method called say() {}.
class Test {
say() {
console.log("I'm a test.");
}
}
Then you created an instance of the Test class below:
let TestFromClass = new Test();
And below that you created a plain JavaScript object called TestFromObject:
let TestFromObject = {
say() {
console.log("I'm also a test.");
}
};
And yes, they will both print out the output you have to their methods:
TestFromClass.say(); // Output: I'm a test.
TestFromObject.say(); // Output: I'm also a test.
The difference will not begin until you utilize the full power of the class you created, for example, utilizing the cconstructor() function like so:
class Test {
constructor() {
}
say() {
console.log("I'm a test.");
}
}
Now the constructor function is automatically called for us when we use the new keyword for the class name. With a constructor function you know also have access to this like so:
class Test {
constructor() {
this.type = 'test';
}
say() {
console.log("I'm a test.");
}
}
Which allows you to do this:
TestFromClass.say(); // Output: I'm a test.
TestFromObject.say(); // Output: I'm also a test.
TestFromClass.type; // Output: test
The constructor is traditionally used to do some initial setup inside the class or particular instance of the class.
The constructor is commonly used by using some arguments when creating a new instance of the class. Maybe you want to specify that the class of Test you have created has 50 questions. You can pass in an object to the new Test instance like so:
let TestFromClass = new Test({ questions: 50 });
You can call this object whatever you want, let's just call the object examination and you can set the number of questions to this examination object.
So now you pass that object into the constructor function and calling that object, examination like so:
class Test {
constructor(examination) {
this.questions = examination.questions;
this.type = 'test';
}
say() {
console.log("I'm a test.");
}
}
let TestFromClass = new Test({ questions: 50 });
TestFromClass.say(); // Output: I'm a test.
TestFromClass.type; // Output: test
TestFromClass.questions; // 50
The other thing you can do with a class object is create a subclass that would extend the functionality of your base class and then you can also add some customized functionality to it.
class Test {
constructor(examination) {
this.questions = examination.questions;
this.type = 'test';
}
say() {
console.log("I'm a test.");
}
}
class Quiz extends Test {
}
So now your Quiz is inheriting all the methods, functions, properties, etcetera that are in the Test class and define additional methods inside of it.
class Test {
constructor(examination) {
this.questions = examination.questions;
this.type = 'test';
}
say() {
console.log("I'm a test.");
}
}
class Quiz extends Test {
constructor(examination) {
this.topic = examination.topic;
}
}
So now to ensure that the constructor function from the parent class is called as well, I can use the super() keyword into the constructor:
class Test {
constructor(examination) {
this.questions = examination.questions;
this.type = 'test';
}
say() {
console.log("I'm a test.");
}
}
class Quiz extends Test {
constructor(examination) {
super(examination)
this.topic = examination.topic;
}
}
Then you can instantiate that subclass like so:
const javascript = new Quiz({topic: 'javascript', questions: 50 });
and finally print it out:
javascript.questions; // Output: 50

How to change class' prototype at runtime within this class (with ES6 classes)

I have the following class 'X' and I want to add some stuff to its prototype dynamically, like this (this works):
class X{
someUnrelatedFunction(){};
}
//adding some stuff at runtime, in real situation, the ['a','b','c'] aren't "known" in advance like here.
['a','b','c'].forEach(elem => {
X.prototype[elem] = () =>{
console.log('called with : ' + elem);
};
})
//tests:
x = new X();
x.c();//works, outputs 'called with : c';
But in the class declaration itself. I would like to do it, to make things a bit more readable, i.e. I would like the 'prototype' initialization to belong to the class itself.
Right now I'm doing this in a 'constructor', like here:
class X{
constructor(){
//we don't want to do that again:
if(typeof X.prototype.inited === 'undefined'){
X.prototype.inited = true;
console.log('-constructor: initing prototype');
['a','b','c'].forEach(elem => {
X.prototype[elem] = () =>{
console.log('called with : ' + elem);
};
})
}else{
console.log('-constructor: no need to re-init prototype');
}
}
}
x1 = new X();
x1.a();
x2 = new X();
x2.b();
fiddle: https://jsfiddle.net/nypL29f3/4/
But this seems tricky for me, plus inside the class I'm actually referencing it kinda "outside", i.e. I'm using "X". If I ever changed the class name, I will also need to change that part of code.
So the question is - how to do that in a more readable and right way?
FWIW, The "real" case scenario is that I'm playing with ES6 by creating useless scripts like this one:
https://jsfiddle.net/kpion/mqyrewnx/9/
Here my doubts were about line #78 //this was my question - that it seems I need to do it outside the class YaLog.
Edit: just BTW - if you came here with a similar question - all the below answers answer the question in a way, and all are worth reading. Thanks everyone! :)

This sort of class prototype modifications is never performed from inside a constructor - primarily because class constructor is responsible for managing current class instance, not all class instances. A constructor is supposed to declare new methods ('log','info', etc) on this class instance, this is less efficient than declaring methods on class prototype and may be desirable or not for further class inheritance.
This is what decorators are intended for. They provide a convenient syntax for extension or modification class constructor and prototype.
A decorator can modify existing class prototype:
function withLogger(Class) {
['log','info','error','warn','group','groupEnd'].forEach(func => {
Class.prototype[func] = function() {
return this.callConsoleMethod(func, ...arguments);
};
});
return Class;
}
Or return a new class that extends existing class in non-destructive way, this allows to refer original members with super when shadowing them in wrapper class.
Decorators have neat syntax in ECMAScript Next/TypeScript:
#withLogger
class YaLog {
...
}
Since a decorator is basically a helper function, it can be applied directly in ES6 in a bit less expressive manner:
const YaLog = withLogger(class YaLog {
...
});

I would like the 'prototype' initialization to belong to the class itself.
That is not possible. A class body can only contain method definitions, not arbitrary code.
If the number of methods was known and only their names are dynamic, you could use computed property names, but this doesn't seem to be the case in your example.
Since you are looking for a more readable way, just put the class and all assignments of static values or dynamically created methods in a separate module. (This might be an ES6 module, an IIFE module, or a simple block scope for visual separation).
Right now I'm doing this in the constructor
Don't. This is inefficient, error-prone and horribly unreadable.

You can use inheritance. Create new class Y and add it methods from your array. Then you can extend original class (or any other) with Y:
class Y {}
const methods = ['a', 'b', 'c']
methods.forEach(elem => {
Y.prototype[elem] = () => {
console.log('called with : ' + elem)
}
})
class X extends Y {
someUnrelatedFunction() {}
}
const x1 = new X();
x1.a();
I am not sure what your use case is, but you can create a helper function which extends your original class. For example this could also work:
function extendWithMethods(methodNames, generalHandler) {
class Y {}
methodNames.forEach(elem => {
Y.prototype[elem] = () => generalHandler(elem)
})
return Y
}
class X extends extendWithMethods(['a', 'b', 'c'], methodName => {
console.log('called with : ' + methodName)
}) {
someUnrelatedFunction() {}
}
const x1 = new X()
x1.a()

How to instantiate a Class from a String in JavaScript

I'm in a weird situation that i need to instantiate a new Class with a string stored in a variable but even i'm sure the class name is correct i get an error that given class name is not a constructor
Here is a dummy code that doesn't work:
class Foo {
constructor(){
console.log('Foo!');
}
};
const foo = 'Foo';
const bar = new window[foo]();
console.log(bar);
This trow this error:
Uncaught TypeError: window[foo] is not a constructor

One possibility is to use eval.
class Foo {
constructor() {
console.log('Foo!');
}
};
const foo = 'Foo';
const bar = eval(`new ${foo}()`);
console.log(bar);
You will have to evaluate the safety of using eval() in your particular circumstances. If you know the origin of the string you are inserting into the code that you run eval() on or you can sanitize it first, then it may be safe.
I personally would prefer a lookup table. If you have a known number of classes that you want to map by string, then you can make your own lookup table and use that. This has the advantage of there can be no unintended consequences if the string has weird stuff in it:
class Foo {
constructor() {
console.log('Foo!');
}
};
class Goo {
constructor() {
console.log('Goo!');
}
};
// construct dict object that contains our mapping between strings and classes
const dict = new Map([
['Foo', Foo],
['Goo', Goo]
]);
// make a class from a string
const foo = 'Foo';
let bar = new(dict.get(foo))()
console.log(bar);
If you were really going to go this route, you may want to encapsulate it in a function and then add error handling if the string is not found in the dict.
This should be better than using the global or Window object as your lookup mechanism for a couple reasons:
If I recall, class definitions in ES6 are not automatically put on the global object like they would with other top level variable declarations (Javascript trying to avoid adding more junk on top of prior design mistakes).
So, if you're going to manually assign to a lookup object, you might as well use a different object and not pollute the global object. That's what the dict object is used for here.

Similar to #jfriend00 ...
const className = "Foo";
const dynamicConstructor = {};
dynamicConstructor[className] = class {
constructor() {
console.log('Foo!');
}
};
const fooInstance = new dynamicConstructor[className]();
console.log(fooInstance);
A sort of factory class constructor can also be used
const classFactory = (_className) => {
let dynamicConstructor = {};
dynamicConstructor[_className] = class {
constructor(_code) {
this.code = _code;
console.log(`${_className} initialised with code: ${_code}!`);
}
};
return dynamicConstructor[_className];
}
const MyClass = classFactory("Foo");
let fooInstance2 = new MyClass(123);
console.debug(fooInstance2);

There are good solutions but I think we need a little bit more of theory
This questions is the best example to use a Factory Pattern
Design patterns can make your code more flexible, more resilient to change and easier to maintain.
Teo, is possible to use Factory Patterns in JavaScript?
Yes, my young Padawan.
But, what is the Factory pattern?
The factory pattern is a creational design pattern, which means it deals with object creation. There are three theoretical types of factory patterns:
Simple factory
Factory method
Abstract factory
Simple Factory is an object which encapsulates the creation of another object. In ES6 it could be a constructor being instantiated by new in a function and then return the instance like this:
class Player {...}
const PlayerFactory = {
makePlayer: (type, level) => new Player(type, level),
}
In this example makePlayer returns the instance of the Player class.
Factory Method defines one method for creating a class instance, which is overridden by subclasses who decide what to return.
In ES6 it could be implemented extending classes because there are no interfaces and using a method to instantiate and object using new
class Dragon {...}
class Snake {...}
class Player {
fightMonster() {
const monster = this.makeMonster()
monster.attack()
}
}
class Warrior extends Player {
makeMonster() {
return new Dragon()
}
}
class Knight extends Player {
makeMonster() {
return new Snake()
}
}
In this example, Player class call makeMonster method then Warrior and Knight classes override makeMoster method to return either a Dragon or a Snake class instance.
Finally, the Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes
The interpretation of families could be like a category or list of classes. In ES6 it can be an instance that encapsulates a group of individual factories with a common goal. It separates the details of implementation of a set of objects from their general usage.
class WinButton {
constructor(options) {
this.name = 'WinButton'
this.options = options
}
}
class LinuxButton {
constructor(v) {
this.name = 'LinuxButton'
this.options = options
}
}
// Mapping names and class definitions
const supportedOS = new Map([
['Windows', WinButton],
['Linux', LinuxButton]
])
// Use a Factory Abstract pattern
const classFactory = (c, v) => {
const maker = supportedOS.get(c)
return new(maker)(v)
}
// Factory a class from a string
const name = 'Windows'
const param = {enabled: true}
const btn = classFactory(name, param)
console.log({btn})
In this final example we can see that the function classFactory uses the Factory Abstract pattern because instantiate a class from a list of supported OS (Linux or Windows) by setting maker with the constructor of the desired class, in this case WinButton class.

Extend a class with private/protected/public fields and methods

I am trying to find a way to create an simili-abstract class in ES6. So far, everything I try always hits the limitations of the langage and/or its syntax (also my limited knowledge about prototyping).
Basic oop; We declare a class and extend it. The final class has to access some fields and methods from its superclass, but not all of them. It also morphs public methods...
The class declarations should be in a perfect encapsulation, so nothing else than this code is be able to reach it (something similar to a namespace).
So far, my experiments in ES5 are wrong... I would really appreciate some advice and help.
(function(){
// ==================================
function AbstractClass(params) {
var _myParams = params;
var _privateField = "Only AbstractClass can see me";
this.publicField = "Everybody can see me";
function privateFunc() {
// Does private stuff
}
}
AbstractClass.prototype.publicFunc = function() {
// Does public stuff
privateFunc(); // Works?
}
// ==================================
function FinalClass(params) {
// How to pass the params to the superclass?
}
FinalClass.prototype.publicFunc = function() {
// Override and calls the superclass.publicFunc()?
// How can I touch _privateField ? publicField ?
}
FinalClass.prototype = Object.create(AbstractClass.prototype);
// ==================================
var foo = new FinalClass("hello world!");
foo.publicFunc();
})();
Can you tell me what is wrong with this code and how to fix it?
Bonus question: How to do this in ES6 properly?
Triple bonus: What about protected fields and methods?
Thank you.

This is actually a very good question and I will try to give you an insightful answer...
As I already explained somewhere on Stack Overflow, JavaScript is not really a class-based language. It is based on prototypes. This is a completely different programming paradigm and you should take this into consideration. So when you write something in Vanilla JS, this is generally a good idea to forget (just a tad) what you know about Java or C++.
However, JavaScript is a very flexible language and you can program as you wish. In my opinion, there are two main styles when it comes to JavaScript programming: an idiomatic style and a classic style.
The idomatic style makes intensive use of object literals, duck typing, factory functions and composition.
The classic style tries to mimic the behavior of class-based languages with constructor functions for classes and IIFEs (Immediately-Invoked Function Expressions) for encapsulation. It lays stress on inheritance and polymorphism.
What you want is an abstract class. An abstract class is a class that cannot be instantiated and is only useful as a model for derived classes. If you care about strict encapsulation, this is how you could implement it in ES5:
// ==============================
// ABSTRACT "CLASS"
// ==============================
var OS = (function (n) {
// Here "name" is private because it is encapsulated in the IIFE
var name = "";
// Constructor
function OS (n) {
// If "OS" is called with "new", throw an error
if (this.constructor === OS) {
throw new Error('You cannot instantiate an abstract class!');
}
name = n;
}
// We cannot call this method directly (except with "call" or "apply") because we cannot have direct instances of "OS"
OS.prototype.boot = function () {
return name + ' is booting...';
};
// This is an abstract method. It will be in the prototype of derived objects but should be overriden to work
OS.prototype.shutdown = function () {
throw new Error('You cannot call an abstract method!');
};
// Getter for "name"
OS.prototype.getName = function () {
return name;
};
// The constructor must be returned to be public
return OS;
})();
// ==============================
// CONCRETE "CLASS"
// ==============================
var LinuxDistro = (function (name) {
// Constructor
function LinuxDistro(name) {
// Here we call the constructor of "OS" without "new", so there will not be any error
OS.call(this, name);
}
// Here "Linux Distro" inherits from "OS"
LinuxDistro.prototype = Object.create(OS.prototype);
LinuxDistro.prototype.constructor = LinuxDistro;
// Private function/method
function textTransform(str, style) {
return style === 'lowercase' ? str.toLowerCase() : str.toUpperCase();
}
// The parent method is used and overriden
LinuxDistro.prototype.boot = function () {
return OS.prototype.boot.call(this) + ' Welcome to ' + textTransform(this.getName());
};
// The abstract method is implemented
LinuxDistro.prototype.shutdown = function () {
return 'Shutting down... See you soon on ' + textTransform(this.getName());
};
// The constructor must be returned to be public
return LinuxDistro;
})();
// ==============================
// CLIENT CODE
// ==============================
var arch = new LinuxDistro('Arch Linux');
console.log(arch.getName());
console.log(arch.boot());
console.log(arch.shutdown());
Now you want the same thing with ES6. The good point is that ES6 provides nice syntactic sugar to work with classes. Again, if you care about strict encapsulation, you could have the following implementation:
// ==============================
// ABSTRACT "CLASS"
// ==============================
const OS = (n => {
// Here "name" is private because it is encapsulated in the IIFE
let name = "";
class OS {
constructor(n) {
// If "OS" is called with "new", throw an error
if (new.target === OS) {
throw new Error('You cannot instantiate an abstract class!');
}
name = n;
}
// We cannot call this method directly (except with "call" or "apply") because we cannot have direct instances of "OS"
boot() {
return `${name} is booting...`;
}
// This is an abstract method. It will be in the prototype of derived objects but should be overriden to work
shutdown() {
throw new Error('You cannot call an abstract method!');
}
// Getter for "name"
get name() {
return name;
}
}
// The class must be returned to be public
return OS;
})();
// ==============================
// CONCRETE "CLASS"
// ==============================
const LinuxDistro = (name => {
// Private function/method
function textTransform(str, style) {
return style === 'lowercase' ? str.toLowerCase() : str.toUpperCase();
}
class LinuxDistro extends OS {
constructor(name) {
// Here we call the constructor of "OS" without "new", so there will not be any error
super(name);
}
// The parent method is used and overriden
boot() {
return `${super.boot()} Welcome to ${textTransform(this.name)}`;
}
// The abstract method is implemented
shutdown() {
return `Shutting down... See you soon on ${textTransform(this.name)}`;
}
}
// The class must be returned to be public
return LinuxDistro;
})();
// ==============================
// CLIENT CODE
// ==============================
const arch = new LinuxDistro('Arch Linux');
console.log(arch.name); // This is not a direct access to "name". The getter is used...
console.log(arch.boot());
console.log(arch.shutdown());
Of course, these snippets are not perfect and may look a bit scary. But I think this is the best we can do, due to the prototypal nature of JavaScript.
As you probably see, class members are either private (thanks to IIFEs and closures) or public (thanks to how objects are created, with their own properties and prototype chain). If you really want protected members, this is another story...
When you have in mind an OOP model for your JavaScript code, I would recommend you to use TypeScript. This is much more convenient, readable and maintainable than the code presented above.
Finally, if you want to go further and see how you could implement all traditional OOP design patterns in JavaScript (especially GoF patterns), I invite you to take a look at a project of mine on GitHub: PatternifyJS

performance of prototype vs passing object property

I have a class that needs a reference to a property from it's parent. I would like to know if it is better to pass in the property to the constructor of the child class and set it as a new property of the child class, or while in the parent class add it as a prototype of the child class.
implemenatation A:
// parent-class.js
let childClass = require('childClass.js');
class foo {
constructor() {
this.initChild = new childClass(this.superCoolMethod);
}
superCoolMethod() {
return 'this method does super cool stuff and the child needs it';
}
}
// child-class.js
class bar {
constructor(superCoolMethod) {
this.superCoolMethod = superCoolMethod;
}
callCoolMethod() {
this.superCoolMethod();
}
}
implemenatation B:
// parent-class.js
let childClass = require('childClass.js');
class foo {
constructor() {
this.childClass.prototype.superCoolMethod = superCoolMethod;
this.initChild = new childClass(this.superCoolMethod);
}
superCoolMethod() {
return 'this method does super cool stuff and the child needs it';
}
}
// child-class.js
class bar {
callCoolMethod() {
this.superCoolMethod();
}
}
Which implementation would be more performant and are there any better ways to achieve this?

Which implementation would be more performant...
It doesn't matter. It's a massively bad idea for class foo to reach out and change the prototype of class childClass. (But the instance property would be very-very-very-slightly faster, because the property lookup stops at the instance, rather than not finding it at the instance and then needing to look to the prototype. In the real world, the odds of it making any noticeable difference at all are near zero.)
Remember: That prototype is used by all other childClass instances, even those completely unrelated to foo code. The link between instance and its prototype is a link; instances don't get a copy of their prototype. So for example:
class Example {
};
const e = new Example();
console.log(e.foo); // undefined
Example.prototype.foo = 42;
console.log(e.foo); // 42
and are there any better ways to achieve this?
Set it as a property on the instance (e.g., implementation A or similar).

I would set it as a property. It is the way it makes sense. If you change the prototype, you will have the added method in all subsequent new childClass() objects. That may not be desired behavior.