What Is the Difference Between a Class and an Object?

We'll endeavor to answer this question by exploring, cookies, cars and then some code. We'll see that a class is a 'template/blueprint' from which we may efficiently create multiple objects.

Cookies

The Holidays just passed recently. Perhaps you and/or your family members baked cookies. Sometimes folks cut these cookies into special shapes - snowmen, Christmas trees, bells, whatever. We can do this in a couple of different ways:

• Cut each individual cookie (object) out of out the flattened dough by hand each and every time
• Use a cookie cutter template (class) to stamp out the cookies consistently

What are some issues with the first option? It will become quite tedious to manually cut the shapes out one at a time. It will waste our energy and time.

On the contrary, the second option will allow us to create many cookies with less time/energy.

In this scenario, our cookie cutter was our class. We then used that class to create instantiate several cookies.

Cars

Cookies are great, but they don't really have any functionality (methods). What about cars?

Generally speaking, the design specifications (class) for manufacturing (instantiating) a particular car (object) are finalized once by some engineers.

Then, when it's time to mass produce, there is no need for the engineers to come down to the manufacturing floor and describe in detail each step of how to build each individual car, right? That would be quite inefficient and a drain on the company's resources.

Instead, the design specifications (class) are followed. Said design specifications (class) specify the materials (properties) and required functionalities (methods) of each car.

A Code Example

Whether it's cookies, cars or code, the principles are the same:

1. Establish a set of guidelines that describe what something is (properties) and what it should do (methods).
2. Mass produce instances of this 'thing.'

For the code example, we'll explore some very simple 'employee objects.' Perhaps something that might become part of an HR system.

Each employee must have:

• First Name
• Last Name
• ID

In addition, each employee can request time off by simply stating their name and saying that need a break.

Let's do this first without any classes.

const bob = {
  fname: "Bob",
  lname: "Smith",
  id: 112334,
  requestTimeOff() {
    return `${this.fname} ${this.lname} needs a break!`
  }
}

const alice = {
  fname: "Alice",
  lname: "Jones",
  id: 112335,
  requestTimeOff() {
    return `${this.fname} ${this.lname} needs a break!`
  }
}

const sam = {
  fname: "Sam",
  lname: "Walton",
  id: 112336,
  requestTimeOff() {
    return `${this.fname} ${this.lname} needs a break!`
  }
}

What are some issues here? Well, we are manually describing each property of each employee each time. Also, requestTimeOff is duplicated for each object, wasting memory and cluttering up our code!

Let's now create a class to encapsulate each 'employee object.'

Create A Template (class)

class Employee {
  // Specify the properties of each 'employee'
  constructor (fname, lname, id) {
    this.fname = fname;
    this.lname = lname;
    this.id = id;
  }

  requestTimeOff() {
    return `${this.fname} ${this.lname} needs a break!`
  }
}

Instantiate Objects

Now, let's create our 3 'employee objects' once again.

const bob = new Employee ('Bob', 'Smith', 112334);
const alice = new Employee ('Alice', 'Jones', 112335);
const sam = new Employee ('Sam', 'Walton', 112336);

Notice how much less code it took to create our 3 employees!

---

No matter if it's cookies, cars or code to create instances of employees. The principle is the same. It makes sense to standardize a collection of specifications one time as a class, and then to reuse that class to 'mass produce' individual objects.