DEV Community

Cover image for Why Switch Statement is Bad
eslamelkholy
eslamelkholy

Posted on

Why Switch Statement is Bad

Why Switch Statement Is Bad

First of all Switch Statement is not bad but sometimes violates Clean Code Principles
So Switch statement should be used very carefully.

Why Switch Statement is Sometimes Bad

  • Violates Open-Closed Principle S(O)LID When adding a new Functionality with a new requirements so i will violate the Open-Closed Principle
  • Maintenance
    By time with a new Requirements it will be very hard to maintain it

  • Bad Code Smell & Bad OOP Style
    containing lots of redundant codes and the code going to be messy with time

Old Example

this Example Violates Open-Closed when we want to add new Functionality at this Function
also we have lots of redundant codes like Order Msg Data

function orderData(STATUS: string): Order {
  const result = new Order();

  switch (STATUS) {
    case ORDER_STATUS.CHECKOUT:
      result.msg = 'Welcome USER';
      result.action = `${ORDER_STATUS.CHECKOUT} Action`;

    case ORDER_STATUS.PAYMENT:
      result.msg = 'Welcome USER';
      result.action = `${ORDER_STATUS.PAYMENT} Action`;

    case ORDER_STATUS.DELIVER:
      result.msg = 'Welcome';
      result.action = `${ORDER_STATUS.DELIVER} Action`;
    default:
      break;
  }

  return result;
}
Enter fullscreen mode Exit fullscreen mode

So Using switch on a type is very bad OOP Style how can we refactor this code ?

The best solution of this is Using ( Polymorphism + Strategy Pattern )

The Below Code is a Solution with Polymorphism & Strategy Pattern

1- Initialize IOrder Interface & Other Payment Processors which have different business logic

interface IOrder {
  getOrderData(): OrderData;
}

class Checkout implements IOrder {
  getOrderData(): OrderData {
    return new OrderData('Welcome USER', `${ORDER_STATUS.CHECKOUT} Action`);
  }
}

class Payment implements IOrder {
  getOrderData(): OrderData {
    return new OrderData('Welcome USER', `${ORDER_STATUS.PAYMENT} Action`);
  }
}

class Deliver implements IOrder {
  getOrderData(): OrderData {
    return new OrderData('Welcome', `${ORDER_STATUS.DELIVER} Action`);
  }
}
Enter fullscreen mode Exit fullscreen mode

2- Add Strategy Design Pattern Which Holds All Payment Processors Objects

class OrderStrategy {
  public CHECKOUT: IOrder;
  public PAYMENT: IOrder;
  public DELIVER: IOrder;

  constructor() {
    this.CHECKOUT = new Checkout();
    this.PAYMENT = new Payment();
    this.DELIVER = new Deliver();
  }
}
Enter fullscreen mode Exit fullscreen mode

3- Now Our getOrderData function clean and Ready to use

function getOrderData(STATUS: ORDER_STATUS): OrderData {
  const orderStrategy = new OrderStrategy();

  return orderStrategy[STATUS].getOrderData();
}
Enter fullscreen mode Exit fullscreen mode

Conclusion

Switch Statement is not bad at all but sometimes it violates OOP, also Breaks Open-Closed Principle

and it's going to be very hard to maintain and and refactor our Code in the future is going to be like a rock in our back
and the best solution to handle
these staff is to use Polymorphism and Strategy Pattern

Source Code

Github Why-Switch-Statement-Bad

Discussion (4)

Collapse
aghost7 profile image
Jonathan Boudreau

I find that switch statements are nice for things like enums. The values are limited so the API can still be kept clear. I think the main issue with your example is with stringly-based API (status is a string) being used in a statically typed language. Its not necessarily that you're using a switch statement.

Collapse
eslamelkholy profile image
eslamelkholy Author

Yea Switch statement is cool but sometimes when new requirements comes up the code maintenance is going to be very hard by time so by adding new features as you mentioned new Enum for example you just need to add new class it's better than editing in the switch statement it self

Collapse
mahmoudmohamedelgamily profile image
Mahmoud-Mohamed-Elgamily

what if we used switch statement inside factory pattern ?

Collapse
eslamelkholy profile image
eslamelkholy Author

very nice one we can use Factory Pattern and Refactor Switch Statement to be exactly the same as we did here