2

I have built a javascript class that does things to the dom. To simplify the use from outside as much as possible I now have methods like these:

hello.add(id);
hello.delete(id);
hello.select(id);

To make the above work, I have setup a static class that uses the non static class like this:

Static class

class hello {
  static add(id) {
    let hello = new HelloCore();
    hello.add(id);
  }

  static delete(id) {
    let hello = new HelloCore();
    hello.delete(id);
  }

  static select(id) {
    let hello = new HelloCore();
    hello.select(id);
  }
}

Non static class

The real code is 500 lines with a constructor and so on.

class helloCore() {
  add() {
    // Do something
  }

  delete() {
    // Do something
  }

  select() {
    // Do something
  }
}

It's now super simple but I wonder if there is a performance issue with this approach. My guess is that it store a new javascript object on every static call into memory?

  1. Do I need to worry about it?
  2. If yes, what would be a better approach, but still super simple?

What I want to stay away from

From the start I had always needed to pass the object around to the functions where it's going to be used. See below.

let hello = new HelloCore();

function my_function(hello) {
  let id = 2;
  hello.add(id);
}

my_function(hello);

With the static approach I don't need to pass the object around everywhere. I can just trigger the function from anywhere.

I could use a global var hello = new Hello(); but then I need to make sure it's loaded first, that I don't forget about it and it means extra code for the user.

Jens Törnell
  • 23,180
  • 45
  • 124
  • 206
  • 2
    With the static class approach the hello instance is not available after function call any more... – marekful Feb 15 '19 at 12:36
  • 1
    I would just keep passing the object around. It's basic dependency injection which makes your code more flexible/extendable/reusable, easier to test, and a bit less obscure in the process. – Jeto Feb 15 '19 at 12:40
  • 1
    At this point, reading your code, I'm wondering why `helloCore` isn't static instead. Currently, you have an information loss in your `hello` static class, since the inner `hello`instance is lost. Is there any "real" code example that gets a bit closer to what you want to achieve? – briosheje Feb 15 '19 at 12:42
  • @briosheje My non static class is over 500 lines and I did not want to write it all out. It as a constructor and so on. – Jens Törnell Feb 15 '19 at 12:44
  • So, if it creates an object instance, I guess it's important, right? I'm wondering what is the point of making a static class to create a **new** instance of an object that becomes immediately unavailable after the function call. Will it be stored in a collection? is it meant to be garbage-collected? There shoulnd't be dramatic performance issues in your approach, since you likely would still create a new instance everytime, right? – briosheje Feb 15 '19 at 12:47
  • @briosheje I have the full project here in case you want to know all about what it does. https://github.com/jenstornell/staircase.js – Jens Törnell Feb 15 '19 at 13:17
  • "*I could use a global `var hello = new Hello();`*" - that's *exactly* the same as you have with your current "static class". Classes aren't special in any way, you need to make sure it's loaded first and not forget to declare it just the same as you need with `var hello`. – Bergi Feb 15 '19 at 15:22
  • What does your constructor do? What state does your `helloCore` class maintain? Notice that with your current approach, every call to one of the static methods creates a fresh new instance. – Bergi Feb 15 '19 at 15:24
  • 1
    You should **never** create a `class` that consists of only `static` methods. You could just as easily use an object literal, which would be much more efficient and appropriate since you don't plan to instantiate anything. In your case: `const hello = { add(id) { new HelloCore().add(id); }, delete(id) { new HelloCore().delete(id); }, … };` – Bergi Feb 15 '19 at 15:26
  • @Bergi Interesting approach. Is there a benefit of const instead of static cass methods? – Jens Törnell Feb 16 '19 at 14:08
  • 1
    @JensTörnell Yes: it doesn't create a constructor function and prototype object that are never needed (and might even be abused, or at least will confuse the reader). – Bergi Feb 16 '19 at 14:30
  • @Bergi I see. I will probably switch to your approach if it works as well as it looks. I'll try it out on monday. You did not add an answer, so I can't set it as the correct one. Thanks! – Jens Törnell Feb 16 '19 at 15:28
  • I haven't posted an answer yet because I'm still not sure what `HelloCore` does (does it have a constructor, does it keep state), and whether the `hello` object is a good idea at all or whether you really should just instantiate a singleton. – Bergi Feb 16 '19 at 16:34

2 Answers2

0

You may want to take a look at Singleton.
It does exactly what you are trying to achieve.

However, I must admit that I (and a lot of other developers) frown upon singletons, globals and static classes, not because of performance, but as a general pattern.
This SO question tells a bit about why singletons are bad.

NemoStein
  • 2,088
  • 2
  • 22
  • 36
0

@mareful commented this helpful information:

With the static class approach the hello instance is not available after function call any more...

It means that the static class will self clean after each call.

Then I got a comment from @Bergi with an idea to use a const including functions with the same result. This approach works really well.

Before - with static class

class hello {
  static add(id) {
    let hello = new HelloCore();
    hello.add(id);
  }

  static delete(id) {
    let hello = new HelloCore();
    hello.delete(id);
  }

  static select(id) {
    let hello = new HelloCore();
    hello.select(id);
  }
}

After - with const

const hello = {
  add(id) {
    new HelloCore().add(id);
  },
  delete(id) {
    new HelloCore().delete(id);
  },
  select(id) {
    new HelloCore().select(id);
  }
};

In both cases I can call it like hello.add(id);. The const version is shorter and has some other advantages in this case as well.

it doesn't create a constructor function and prototype object that are never needed (and might even be abused, or at least will confuse the reader).

Jens Törnell
  • 23,180
  • 45
  • 124
  • 206