Static vs Instance Members

Instance members: one copy per object

An instance field is declared on the class but allocated per object — every new Employee(...) gets its own slot for name and salary. Inside a method, you reach the current object's own copy through this: this.salary. Calling alice.giveRaise() touches only Alice's salary; Bob's is completely separate. That independence is the whole point of objects.

class Employee {
  name: string;
  salary: number; // instance field — one per object

  constructor(name: string, salary: number) {
    this.name = name;
    this.salary = salary; // each object gets its OWN salary
  }

  giveRaise(amount: number) {
    this.salary += amount; // 'this' = the specific object
  }
}

const alice = new Employee("Alice", 100);
const bob   = new Employee("Bob", 90);
alice.giveRaise(10); // alice.salary → 110, bob.salary still 90

Static members: one copy, shared by all

A static member belongs to the class, not to any object. There is exactly one copy no matter how many objects exist — or even if zero exist. You don't need this, because there's no particular object involved; you call it on the class name itself, like Employee.company or Employee.headcount(). Change it once and every object that reads it sees the new value, because they're all reading the same single box.

• Static field — shared data: a company name, a configuration constant, a running counter of how many objects exist.
• Static method — behavior that doesn't need a specific object: a factory like Employee.fromCsv(...), or a helper like Math.max(...).
• No this — a static method can't read this.salary, because which object's salary would it mean? There isn't one.

class Employee {
  static company = "Acme";   // ONE shared box for every employee
  static count = 0;          // a static counter

  name: string;
  constructor(name: string) {
    this.name = name;
    Employee.count++;        // bump the shared counter on each hire
  }

  static headcount() {       // static method — no 'this'
    return Employee.count;
  }
}

const a = new Employee("Alice");
const b = new Employee("Bob");
Employee.company = "Globex"; // change ONCE → every employee sees "Globex"
Employee.headcount();        // 2 — read off the class, not an object

When static makes sense

Static shines when the data or behavior truly belongs to the concept, not to any one object: a counter of live instances, a factory method that builds objects, a constant like Math.PI, or a stateless utility function. The test: ask "would this value differ from object to object?" If no — it's static.

Reach for a static member when…

• The value is the same for every object and belongs to the concept, not an instance — a company name, an app-wide config, a constant like Math.PI.
• You're counting instances or holding a shared registry — Employee.headcount, a cache, a connection pool.
• You need a factory method that builds objects before any object exists — User.fromJson(...), Logger.getInstance().
• The function is a pure utility with no per-object state — Math.max(a, b), StringUtils.capitalize(s).