Daily Tips
You are here: / / / Avoid switch Statements (Part 2)

Avoid switch Statements (Part 2)

/by

Avoid switch Statements (Part 2)

switches

Today we’ll continue our examination into the switch statement, and why we programmers should avoid it – started here. Let’s get straight into it. Another reason why the switch statement doesn’t help us write great code is this: Usually switch statements violate the Single Responsibility Principle (SRP). The SRP says that each software module or class should have only one responsibility. The originator of the SRP, Robert Martin, has clarified that this is an often misunderstood principle – it’s about each class only being responsible to one group of stakeholders that can demand changes to the code in that class.

To illustrate what I mean, let’s revisit yesterday’s Pay() method. It contains a switch for selecting a payment gateway and then pays for the shopping cart:

 

  public void Pay(ShoppingCart cart, string paymentGateway)
  {
     switch (paymentGateway)
     {
        case "Paypal":
           // ... code to pay for shopping cart with Paypal.
           break;
        case "Stripe":
           // ... code to pay for shopping cart with Stripe. 
           break;
        default:
           throw new UnknownPaymentGateway(paymentGateway);
     }
  }

Question: Who are the people that require us to make changes to the payment code for Stripe? Answer: It’s the developers at Stripe that do that. If they change their API in a breaking way, then we must change our client code. If we don’t, our Stripe payments will no longer work. Same for Paypal or another payment gateway.

On the other hand, who are the people that decide that our software should be able to switch between Stripe and Paypal? It’s the people that make those kinds of decisions in our company – Product Owners, Managers, etc..

According to the SRP, since two different sets of people make decisions regarding the contents of the switch statement, the switching itself and the code in the case statements should not be together in the class. The Stripe client code and the Paypal client code should each live in a separate class, also separated from the switch statement code.

Here is another way to look at it: We can think of the selection of the payment gateway as a high-level policy – the ability to pay with different payment gateways, whatever those might be. On the other hand, the detail of how we implement the payment gateway client code is a low-level mechanism. Or in other words, that we can choose Stripe or Paypal or another payment gateway is a quite separate thing from the actual workings of the Stripe or Paypal payment code. And it’s lousy programming form to group high-level, abstract policy code together with low-level concrete mechanism code.

Ok, that is a bit to take in, I think. I know that this high-level policy vs low-level mechanism stuff can sound a bit abstract and pie-in-the-sky. However, thinking about the mechanics of programming is a worthwhile exercise. Without such holistic reflection, we’ll only work on our current, local problems, not seeing the bigger picture: A slowly decaying system.

Next time, I want to look at how switch statements are also not Open-Closed Principle compliant. After that, I’ll show you an elegant alternative to switch statements. 

 

Avoid switch Statements Avoid switch Statements (Part 3)