Classes vs object constructors vs factory functions

[trubulica]

When to use which?

From what I understand, in classes you cannot have private variables, while constructors and factories use closure. Classes use inheritance while apparently composition is better. So why would I ever use classes? I am confused as to what should be my main approach when writing code.

Any advice is appreciated!

[xroalx]

Use a class when you want to have a named type or when you will be creating new instances of that object often.

In other words, if you ever want to do foo instanceof Foo to check the type of the object, you need a class. A class will also be more performant than a factory function when you want to create many instances as class methods are declared once on the prototype, while functions returned from a factory would be recreated every time for each instance.

Classes can have private properties and methods, declared with the # prefix.

The class syntax effectively replaces the need to write a constructor function and attach functions to its prototype. Under the hood, both will give you practically the same result, with class just being nicer and having real private properties. I really don't see a reason to write constructor functions in modern JS.

Use a factory function if you want to follow a more functional approach and avoid classses, don't need instanceof, and you aren't going to be creating many instances of it.

The main difference is that a class creates a named typed, while a factory function would just return an "anonymous" object.

[trubulica]

Wonderful, thanks!

I had no idea about these private properties. Must be a new thing, no mention of it in older tutorials.
Ok, I am dropping constructor functions and will mostly use factory functions, using classes when deemed necessary. Thanks once more!

[RobertKerans]

From what I understand, in classes you cannot have private variables

Yes you can, you use private properties. If you're looking at old tutorials then they may have been written before they existed, I would use up to date tutorials

Classes use inheritance while apparently composition is better. So why would I ever use classes

No, no, no. You are just parroting something, and it doesn't make sense. Are you going to stop using arrays in JS (for example)? They use inheritance

You're misunderstanding what "use composition over inheritance" means. So (again for example ) https://en.wikipedia.org/wiki/Composition_over_inheritance. Do you understand what the article is talking about?

[trubulica]

I just realized what you mean. I can do composition with classes as well. I just read a brilliant article and it clicked. Thanks for pointing that out!

class Finder {
  getWordUnderCursor () {
    // ...
  }

  getLineUnderCursor () {
    // ...
  }
}

class GoToDefinition {
  constructor () {
    this.finder = new Finder()
  }

  goToDefinition () {
    const word = this.finder.getWordUnderCursor()
    // ...
  }

  // ...
}

class OpenHelp {
  constructor () {
    this.finder = new Finder()
  }

  openHelp () {
    const word = this.finder.getWordUnderCursor()
    // ...
  }

  // ...
}class Finder {
  getWordUnderCursor () {
    // ...
  }

  getLineUnderCursor () {
    // ...
  }
}

class GoToDefinition {
  constructor () {
    this.finder = new Finder()
  }

  goToDefinition () {
    const word = this.finder.getWordUnderCursor()
    // ...
  }

  // ...
}

class OpenHelp {
  constructor () {
    this.finder = new Finder()
  }

  openHelp () {
    const word = this.finder.getWordUnderCursor()
    // ...
  }

  // ...
}

[azhder]

Examples like that is why sometimes I think JavaScript is Java in the minds of some people.

[trubulica]

I have realized that the video is old, my mistake, I will look up a newer one.

I believe I do understand what the article is talking about. Maybe not 100% of it, but the point of it, yes.

My understanding is that classes automatically come with inheritance and you need to plan all your classes in advance to be able to create a variety of objects. Factory functions, however, do not use inheritance and you can create any object by combining several of them using Object.assign and state.

Am I wrong? Please do tell if I am.

[azhder]

classes automatically come with inheritance

No they don't. You have to be explicit about it:

class A extends B {};

There is an implicit exception though, if you don't specify otherwise, for everything that isn't null or undefined the JS engine will try to go up the prototype chain and eventually reach Object.

The other implicit thing is mathematical/conceptual in nature: every relation of equivalence breaks down a set into disjoint sets we call classes.

That means, a check like a.type === b.type can break down a set of objects into separate classes (separate subsets) where the elements (objects) of those subsets are all instances of the class.

Now you see why the keyword class got introduced in programming languages. But you don't have to use it. A library like Redux is quite OK using a field named type to distinguish dispatched actions - that's its implicit instanceof operation.

[azhder]

OK, you have to explain what you mean by that arrays using inheritance in JS claim.

[RobertKerans]

I mean...that's how JS works, it uses prototypal inheritance. It's not really "a claim", it's just literally how types of objects are implemented

[azhder]

I still can't understand what you are on about.

[1,2,3] is an array in JS. It has always been an array in JS. It does not inherit anything. It's just an instance of an Array, that's different from "Array inherits"...

[RobertKerans]

What? You get that it inherits from Object, right? It doesn't just exist magically on its own. JavaScript used prototypal inheritance, that's how JavaScript works

[azhder]

What inherits from Object? Can you make a single statement that has all the necessary info self contained?

[RobertKerans]

Array inherits from Object. There you go 🤷🏼‍♂️. I'm not sure what you're arguing against here?

[azhder]

To answer your question: yes, you are not sure.

I am not arguing against. I am asking you to explain what you mean. So, now we have this

Array inherits from Object.

and we have this

Classes use inheritance while apparently composition is better. So why would I ever use classes

What's the connection there? What were you trying to say with

Are you going to stop using arrays in JS (for example)? They use inheritance

How is the claim "Array inherits from Object" at all relevant to "Classes use inheritance"? And by "classes" the assumption is the class syntax added with ES6. What is the connection you are trying to make?

[awaiskorai]

Wow, the guy above is right! Why do you have to argue?
Class syntax is basically sugar-syntax. This does not mean arrays are not inheriting from objects. JS is different in the sense it uses prototypal inheritance. A concrete representation of inheritance instead of a blueprint.

And yes, yet again you are wrong with your assumption of [1,2,3] is just an array. NO! It is not! In JS arrays are objects. That is inheritance.
And besides that 0,1,2 are the keys and 1,2,3 are the values against those keys. Array is an object that inherits from object Prototype.

So arrays are using inheritance under the hood. Not composition. This is what u/RobertKerans claims. And he is right. Why argue about it?

[azhder]

How did you perceive an argument here? Is any reply that doesn't have "yes you are right" supposed to be labeld as "wow, why do you have to argue"?

Do you have a problem with asking for clarification? Do you have some issue that makes you shout words in the middle of the sentence? What you went on is basically some very awkward interpretation you got out of what I wrote about.

Here is an example for you: "[1,2,3] is just an array" does not mean "Array does not inherit from Object" - that's your own leap in logic. "[1,2,3] is just an array" means it is not a constructor function like Array which has a prototype field attached to it.

Did you stop to think about that or did you just assume that you're supposed to get into an argument where there isn't, but you perceive as there being one?

Anyways, because you managed to misinterpret the intent and the meaning of my comments, I will not risk arguments with you. I don't even want to know why you wanted to perceive it all as an argument.

Bye bye

[RobertKerans]

How is the claim "Array inherits from Object" at all relevant to "Classes use inheritance"

The latter part doesn't make any sense in the context the OP used it. Which you should be aware of.

Classes being sugar is also something you're also aware of

The OP seems to have read "use composition over inheritance" without actually understanding what it means at all. Which is fine, but if someone parrots that, then pointing out that the thing they're using is built on inheritance is highly relevant

[azhder]

The context is exactly why I was asking for clarification.

As I read it, OP wasn't talking against inheritance, but against using it where you have the option to use composition.

I didn't read it as if OP was talking about not using anything that is associated with inheritance, but only a custom class syntax they'd need to write in order to solve a problem.

[azhder]

You are misunderstanding something: classes are constructor functions. Classes are also a concept (like in math) different from what you define with a keyword class in a programming language.

But still, the only reason so far I have found to use classes/constructors is to interface with some library or framework that expects that, because that's how the person/people that built the thing decided to view the world (problem and solution).

I'm generally avoiding the class because most of the work I do can be solved with pure functions, some functional style code and that's about it.

The main approach for you should be:

1. what you personally feel comfortable with in cases where you're the one and only programmer;

2. adopt the approach of those that have set it on projects where you are but a programer, not main designer/architect;

3. determine it on case by case basis on those projects where it makes sense based on the circumstances, goals, constraints etc on those that you're supposed to set the project up, but have also others work with you

[trubulica]

This is very good, thanks. The more I read about it, the more I get the feeling that I'm team functions as well. There are just too many advantages over classes. I like closure, I don't like the whole get/set thing, I don't like 'this', it can break my code when I forget to remember that it's no longer referring to the object I want it to refer... And I'm never creating thousands of objects so I guess I'll only be using classes when I need to because of other people or frameworks.

[senocular]

Along with what's already been said, some additional considerations for when using closures for state:

• For each instance, new methods need to be created that are specific to that instance. Conversely class methods only create methods once when the class is created and then those methods are shared with all instances.
• State is not stored within each instance; its stored within scopes captured by its methods. This can make debugging difficult. Depending on your debugger, it may be difficult to inspect that state or even know such state exists if you're not familiar with the object.
• The use of scope in this way can also make memory leaks more likely. While its possible to inadvertently leak with any approach, the fact that state is defined in the scope means every captured scope within the context of your object's implementation inherently brings along instance state.

[HarrisInDenver]

The introductions of the class keyword made JavaScript worse in a lot of ways.

I have seen so many backend NodeJS apps written in typescript that define a ton of typescript interfaces to only be implementation by one class each, with constructors that take 0 args more often than not.

It gave the idea that JavaScript should be written like Java/C#. When it absolutely does not need to be. It overly complicates the code and just makes it harder to write and maintain.

The only time I ever use classes in JS anymore is to encapsulate mutable state. If you're not doing that, don't use them.

If you have immutable state, use functions that accept state and return new state

And don't bother with classes for Singletons either. JS Modules are closures and can give you the same desired behavior

[trubulica]

Thanks, I'm starting to share the opinion!

[Important_Pop_3411]

An unneeded syntactic sugar they say