How to create an object in JavaScript

In JavaScript, object literals provide a convenient way to create objects using a simple syntax. An object literal is a comma-separated list of name-value pairs wrapped in curly braces. This approach allows for quick object creation without the need for additional syntax or boilerplate code.

const person = {
  name: "John Doe",
  age: 30,
  occupation: "Software Developer"
};

In the example above, we define a person object that contains three properties: name, age, and occupation. Each property is defined by a key (the name of the property) and a corresponding value. This structure makes it easy to visualize and understand the data encapsulated within the object, as well as to access and manipulate those properties.

Accessing properties in an object literal can be done using either dot notation or bracket notation. Dot notation is straightforward and typically preferred for its readability:

console.log(person.name); // Outputs: John Doe

However, bracket notation can be useful when dealing with dynamic keys or keys that are not valid identifiers:

console.log(person["age"]); // Outputs: 30

Another advantage of using object literals is that they can also include methods, allowing for encapsulated behavior within the object itself. Methods can be defined just like properties, but instead of a value, they hold a function:

const car = {
  make: "Toyota",
  model: "Corolla",
  start: function() {
    console.log("Car started");
  }
};

In this example, the car object has a method called start. This method can be invoked to perform an action related to the object:

car.start(); // Outputs: Car started

Object literals can also be nested, allowing for complex structures that can represent more intricate data models. For instance, a company object could contain multiple employee objects:

const company = {
  name: "Tech Solutions",
  employees: [
    { name: "Alice", position: "Developer" },
    { name: "Bob", position: "Designer" }
  ]
};

Here, the company object has a property employees, which is an array of employee objects. This structure allows for a clear representation of relationships between entities, making it easier to manage and query data.

When defining object literals, it’s important to consider the implications of mutable state. Since objects are reference types in JavaScript, changes made to an object will affect all references to that object. This can lead to unintentional side effects if not managed carefully:

const original = { value: 10 };
const copy = original;

copy.value = 20;
console.log(original.value); // Outputs: 20

In the example above, both original and copy reference the same object in memory. Thus, modifying copy also changes original. To create a true copy of an object, one would typically use methods like Object.assign() or the spread operator:

const original = { value: 10 };
const copy = { ...original };

copy.value = 20;
console.log(original.value); // Outputs: 10

This behavior highlights the importance of understanding how object literals operate within the context of JavaScript’s memory model. As we continue to explore object creation techniques, the nuances of object literals will serve as a foundational concept that informs our approach to more complex patterns.

Creating objects with constructors

While object literals are excellent for creating single, unique objects, they become cumbersome when we need to produce multiple objects with the same structure and behavior. In such cases, constructor functions offer a more systematic and reusable pattern. A constructor function is, in essence, a regular function used with the new keyword to create and initialize objects.

By convention, the names of constructor functions are capitalized to distinguish them from regular functions. Inside the constructor, the this keyword refers to the new object being created, allowing us to assign properties to it.

function Person(name, age) {
  this.name = name;
  this.age = age;
}

To create a new object, or an “instance,” from this constructor, we invoke it with the new operator. This operator orchestrates the object creation process, resulting in a new object configured according to the constructor’s logic.

const person1 = new Person("Alice", 28);
const person2 = new Person("Bob", 35);

console.log(person1.name); // Outputs: Alice
console.log(person2.age);  // Outputs: 35

The new keyword is responsible for several key steps. First, it creates a new, empty plain JavaScript object. Second, it sets the new object’s internal [[Prototype]] property to be the constructor function’s prototype object. Third, it binds the this keyword to the newly created object for the duration of the function call. Finally, it returns the new object, unless the constructor explicitly returns a different object.

A common pitfall when using constructors is defining methods directly within the function body. While this works, it is inefficient from a memory perspective, as a new function object is created for every single instance of the object.

function Car(make, model) {
  this.make = make;
  this.model = model;
  
  // Inefficient: a new function is created for each Car instance
  this.displayInfo = function() {
    console.log(${this.make} ${this.model});
  };
}

A more optimized approach is to leverage JavaScript’s prototype chain. All objects created from a constructor share the same prototype object, which is accessible via the constructor’s prototype property. By adding methods to this shared prototype, we ensure that all instances share a single copy of the method, rather than each having its own.

function Car(make, model) {
  this.make = make;
  this.model = model;
}

// Efficient: method is shared among all instances
Car.prototype.displayInfo = function() {
  console.log(${this.make} ${this.model});
};

const car1 = new Car("Honda", "Civic");
car1.displayInfo(); // Outputs: Honda Civic

When car1.displayInfo() is called, JavaScript doesn’t find the method on the car1 object itself. It then looks up the prototype chain and finds the method on Car.prototype. Crucially, the value of this within the displayInfo method correctly refers to car1, the instance on which the method was called. This mechanism provides both code reuse and proper encapsulation.

This pattern also gives us a reliable way to check the “type” of an object using the instanceof operator, which verifies whether an object’s prototype chain includes the constructor’s prototype object.

const car1 = new Car("Honda", "Civic");

console.log(car1 instanceof Car);     // Outputs: true
console.log(car1 instanceof Object);  // Outputs: true

Utilizing factory functions for object creation

An alternative to constructors for creating objects is the factory function pattern. A factory function is any function that returns a new object without being a constructor or class. This pattern sidesteps the complexities associated with the new keyword and the behavior of this, offering a simpler, more direct approach to object instantiation.

In its most basic form, a factory function is simply a function that encapsulates the logic for creating an object and returns it. This removes the ceremonial requirement of using new and helps prevent common errors, such as forgetting to use new when invoking a constructor, which can lead to polluting the global scope.

function createPerson(name, age) {
  return {
    name: name,
    age: age,
    describe: function() {
      console.log(${this.name} is ${this.age} years old.);
    }
  };
}

const person1 = createPerson("Alice", 28);
person1.describe(); // Outputs: Alice is 28 years old.

One of the most compelling advantages of factory functions is their natural ability to create objects with truly private state using closures. Since the variables declared inside the factory function are not properties of the returned object, they are inaccessible from the outside, effectively creating private members. This provides a robust form of encapsulation that is not as easily achieved with constructor functions prior to the introduction of private class fields.

function createBankAccount(initialBalance) {
  let balance = initialBalance; // This is a private variable

  return {
    deposit: function(amount) {
      if (amount > 0) {
        balance += amount;
      }
    },
    withdraw: function(amount) {
      if (amount > 0 && amount <= balance) {
        balance -= amount;
      }
    },
    getBalance: function() {
      return balance;
    }
  };
}

const account = createBankAccount(100);
console.log(account.getBalance()); // Outputs: 100
account.deposit(50);
console.log(account.getBalance()); // Outputs: 150
console.log(account.balance);      // Outputs: undefined

However, this pattern is not without its trade-offs. Just as with the naive constructor pattern, defining methods directly inside the factory leads to each created object having its own copy of those methods. This can result in higher memory consumption when creating a large number of instances. Furthermore, objects created by a factory function do not have a direct link to their factory via the prototype chain, which means the instanceof operator cannot be used for type checking.

const person2 = createPerson("Bob", 35);
console.log(person2 instanceof createPerson); // Outputs: false

To address the memory inefficiency, we can combine the factory pattern with a shared prototype object. By creating a separate object to hold the methods and using Object.create() within the factory, we can ensure that all instances share the same methods. This approach gives us the best of both worlds: the simplicity and encapsulation of a factory, with the memory efficiency of prototypal sharing.

const personBehavior = {
  describe: function() {
    console.log(${this.name} is ${this.age} years old.);
  }
};

function createPersonWithSharedBehavior(name, age) {
  const person = Object.create(personBehavior);
  person.name = name;
  person.age = age;
  return person;
}

const person3 = createPersonWithSharedBehavior("Charlie", 42);
person3.describe(); // Outputs: Charlie is 42 years old.

This refined pattern provides a clear and explicit way to manage object creation and behavior, avoiding the implicit machinery of the new keyword while still leveraging the power of the prototype system.

I would be interested to hear how you have approached this in practice.