Switch Statements Break the Open/Closed Principle – Use Objects or Maps Instead

When reading large company front‑end codebases (e.g., Google, Meta), you may notice that switch statements appear rarely, and are often absent from core modules.

In projects that prioritize maintainability, scalability, and readability, the drawbacks of switch statements become evident, turning them into a source of "code smell".

Open/Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

In other words, when requirements change and new features need to be added, we should extend the code rather than modify existing code.

Consider a function that returns different permissions based on a user role:

function getPermissions(role) {
  let permissions;
  switch (role) {
    case 'admin':
      permissions = ['create', 'read', 'update', 'delete'];
      break;
    case 'editor':
      permissions = ['create', 'read', 'update'];
      break;
    default:
      permissions = [];
  }
  return permissions;
}

Adding a new "collaborator" role requires modifying the function to add another case, which violates the Open/Closed principle.

In a large system, such switch logic can be scattered across many files and modules; each new feature forces you to locate and modify every related switch, risking bugs if any instance is missed.

Additional problems with switch statements include:

Code verbosity and error‑prone breaks: each case needs a break, and forgetting it causes fall‑through.

Mixed responsibilities: large switch blocks couple many different scenarios in one function.

Reduced readability: when cases exceed three or four, the statement quickly becomes bulky.

Alternative: Embrace Objects and Maps

In JavaScript, the most common and simple replacement is using an object or a Map for strategy mapping.

Solution 1: Object Literal (Dictionary Pattern)

const permissionMap = {
  admin: ['create', 'read', 'update', 'delete'],
  editor: ['create', 'read', 'update']
};

function getPermissions(role) {
  // Use the mapping with a default fallback
  return permissionMap[role] || [];
}

// Adding a collaborator role only extends the map
permissionMap.collaborator = ['create', 'read'];

When adding the collaborator role, the getPermissions function remains unchanged; only the permissionMap object is extended.

Solution 2: Using a Map Data Structure

A Map can have keys of any type (objects, functions, etc.), offering more flexibility than plain objects when needed.

In large front‑end projects with long code lifecycles, maintainability and extensibility are paramount. switch statements inherently violate the Open/Closed principle, making code fragile under change, whereas object/Map mappings and strategy patterns provide more flexible, maintainable structures.