DEV Community: Michael B

Replacing Switch Statements with ChainStrategy

Michael B — Sun, 28 Jul 2024 18:56:03 +0000

Problem Statement

This article is a quick introduction and example of implementing a strategy via the ChainStrategy library. Please see the official documentation for more information and samples.

Sometimes we have use cases in our code that lead to natural logical branches where a process separates into sub-processes and may return a common response.

In the example below, a service implementing a use-case runs conditional logic depending on what the request is doing.

public class TrackingService
{
    private readonly IUpsDependency _upsDependency;
    private readonly IFedexDependency _fedExDependency;
    private readonly IUspsDependency _uspsDependency;

    public TrackingService(
        IUpsDependency upsDependency,
        IFedexDependency fedExDependency,
        IUspsDependency uspsDependency
    )
    {
        _upsDependency = upsDependency;
        _fedexDependency = fedexDependency;
        _uspsDependency = uspsDependency;
    }

    public TrackingResponse TrackPackage(TrackingRequest request)
    {
        if (request.trackingNumber == upsCode)
        {
            return TrackUps();
        }
        else if (request.trackingNumber == fedExCode)
        {
            return TrackFedEx();
        }

        return TrackUsps();
    }

    private TrackingResponse TrackUps()
    {
        // Ups implementation
    }

    private TrackingResponse TrackFedEx()
    {
        // FedEx implementation
    }

    private TrackingResponse TrackUsps()
    {
        // Usps implementation
    }
}

This code, while workable, is sub-optimal. The problems with this code sample are:

We have private methods when we should have public ones.
Unit testing requires mocking dependencies which may not be used

A strategy here would allow us to break each condition into an individual handler. This would transform our use case into smaller chunks that each fulfill a single responsibility. This allows us to easily unit test each handler without having to stub and mock dependencies that each condition does not rely on.

Enter the Strategy

The strategy pattern is a simple way to employ an object-oriented switch statement. You can divide a problem into multiple handlers, each with its specific dependencies. This directly leads to easier automated testing because each test can focus on a single purpose.

A Strategy is best used when:

You have conditional logic that has complex processes
Each process shares common input and output

The Strategy pattern is a low-usage pattern. It does not need to replace every switch statement in your code.

Every strategy has a dedicated request and response object.

public class TrackingResponse
{
    // response properties
}

public class TrackingRequest : IStrategyRequest<TrackingResponse>
{
    // request properties
}

For each possible logical condition, we will define a custom handler that only uses the required dependencies to fulfill each logical branch.

public class FedexTrackingHandler : IStrategyHandler<TrackingRequest, TrackingResponse>
{
    private readonly IFedexDependency _fedExDependency;

    public FedexTrackingHandler(IFedexDependency fedExDependency)
    {
        _fedexDependency = fedexDependency;
    }

    public async Task<TrackingResponse> Handle(TrackingRequest request, CancellationToken cancellationToken)
    {
        // implementation
    }
}

Testing each handler is a lot easier than trying to write tests for a larger service because you are mocking and testing fewer dependencies and logical branches.

[TestClass]
public class FedExTrackingHandlerTests
{
    private readonly Mock<IFedexDependency> _fedex;

    public FedexTrackingHandlerTests()
    {
        _fedex = new Mock<IFedexDependency>();
    }

    [TestMethod]
    public void Handler_Condition_IsCorrect()
    {
        // implement tests
    }
}

Finally, we need to create a profile which will be used to determine what handler to use.

public class TrackingProfile
{
    public TrackingProfile()
    {
        AddStrategy<FedExTrackingHandler>(x => x.TrackingNumber == fedExCode);
        AddStrategy<UpsTrackingHandler>(x => x.TrackingNumber == upsCode);
        AddStrategy<UspsTrackingHandler>(x => x.TrackingNumber == uspsCode);
    }
}

Utilizing our new strategy from a controller is easy:

[ApiController]
[Route("[controller]")]
public class PackageController : ControllerBase
{
    private readonly IStrategyFactory _factory;

    public PackageController(IStrategyFactory factory)
    {
        _factory = factory;
    }

    [HttpGet("{trackingNumber:int}")]
    public async Task<IActionResult> TrackPackage(int trackingNumber)
    {
        var response = await _factory.Execute(new TrackingRequest(trackingNumber));

        return Ok(response);
    }
}

Conclusion

Use cases with complex conditional logic tend to lead to large services that tend to have lots of dependencies and private methods. This results in a frustrating testing experience when dealing with lots of mocking and brittle conditional testing. A Strategy may help to alleviate this situation by breaking up a problem into smaller chunks that can be implemented and tested in isolation from other code blocks. This leads to a stronger code base that is easier to maintain in the long run.

Prefer Empty Objects over Compiler tricks

Michael B — Sat, 20 Jul 2024 16:49:02 +0000

Listen to the Compiler

There are certain situations in C# where you have nullable references that are not initialized in the constructor. The most common situation is Entity Framework navigation properties.

The following shows an Entity Framework entity "Airplane" that has a navigation property of "AircraftType".

public class Airplane
{
    // other fields and methods

    public AircraftType AircraftType { get; }
}

This will produce a CS8618 - Resolve Nullable Warnings error. The compiler is telling us we have a nullable object that is leaving the constructor without being initialized. This will throw a null reference exception if we attempt to de-reference the object.

The issue is that we know that the object will be initialized, but the compiler does not.

The most common solution is to use the "default!" trick to tell the compiler to ignore this nullable situation.

public class Airplane
{
    public Airplane()
    {
        AircraftType = default!;
    }

    public AircraftType AircraftType { get; }
}

This is not ideal due to silencing the compiler. We are leaving our application in a possible situation of undefined behavior. Unit testing or running the application without the database will yield possible errors. We need to ensure that de-referencing the property in any situation will not throw exceptions.

var airplane = new Airplane();

// Null reference exception will occur.
var aircraftType = airplane.AircraftType;

Putting null checks everywhere in your code is not an ideal situation either. Due to each null check requiring a unit test against it.

You should adhere to a strict policy of putting the compiler first. Nothing, including you, is above it.

Instead of using the "default!" trick, use an object that contains empty data to satisfy the compiler. This is a variant of the null object pattern. Using an empty object will use default values in place of real-life data.

public class AircraftType
{
    // implementation

    public static AircraftType EmptyObject()
    {
        return new AircraftType(Guid.Empty(), string.Empty, 0);
    }
}

Your other class will be updated like so:

public class Airplane
{
    public Airplane()
    {
        AircraftType = AircraftType.EmptyObject();
    }

    public AircraftType AircraftType { get; }
}

Conclusion

Using empty objects over silencing the compiler will lead to more consistent behavior in your application. Warnings from the compiler are a stern indicator that a change is needed. It is of the utmost importance to listen to what your application is telling you. Transforming your code to be implementation agnostic is one way to future-proof yourself and others on your team from future headaches.

Simplifying State Updates for Reference Types

Michael B — Sun, 14 Jul 2024 17:15:44 +0000

The Problem

If you are working in React, Vue, or Angular you've probably had issues with state objects updating and re-rendering properly. This is because reference types in JavaScript/TypeScript must be deep-cloned properly to ensure that framework state hooks can pick up changes properly.

const [state, setState] = useState<MyObject>();

state.property = "newValue";

setState(state);

The following code snippet does not do what you think it does. Because the "state" object is the same reference, the state hook or "ref" in Vue is unable to detect the change in the property.

The correct way to accomplish this state update is to perform a full deep clone of the state object.

const [state, setState] = useState<MyObject>();

const newState = { ...state };
newState.property = "newValue";

setState(newState);

However, the frustration with this method is magnified when you have state objects with multiple levels that must all be deep-cloned individually. It leads to a serious boilerplate issue that pollutes code bases. Many developers choose to rectify this by serializing and deserializing the object, however, this is a band-aid over a bigger issue.

const [state, setState] = useState<ComplicatedObject>();

const newState = JSON.parse(JSON.stringify(state)) as ComplicatedObject;
newState.property.subProperty = "newValue";

setState(newState);

This method works, but it is ugly as it requires a suboptimal way of producing a deep clone that must be hard-casted to the correct type.

Solution

There is a built-in method in Node that natively provides deep clone capability without the code smells. We can wrap this method in a custom hook to give us consistent state updates without future headaches.

StructuredClone is a new addition to Node, so this method may not work for all projects.

import { useState } from "react";

export default function useDeepState<T>(
  initialState: T
): [T, (newState: T) => void] {
  const [state, setState] = useState<T>(initialState);

  const updateState = (newState: T): void => {
    setState(structuredClone<T>(newState));
  };

  return [state, updateState];
}

If you are using Vue...

import { Ref, ref } from "vue";

export default function useDeepState<T>(
  initialState: T
): [Ref<T>, (newState: T) => void] {
  const state = ref<T>(initialState) as Ref<T>;

  const setState = (newState: T): void => {
    state.value = structuredClone<T>(newState);
  };

  return [state, setState];
}

The StructuredClone method is usable in most modern front-end frameworks to give developers a type-safe, native implementation of the deep clone algorithm. We have simply wrapped the method in a new hook that may be reused in our application.

This new hook is only required for reference types. Primitives need not apply.

With this new implementation, you may update any state reference type by simply changing the property or field. No more custom cloning, JSON workarounds, or frustration.

Conclusion

State fundamentals can be tricky in front-end frameworks. State for reference types has a few extra caveats that if not properly understood can lead to frustration and undefined behavior in applications. Having a consistent and reliable method for updating reference types via StructuredClone is one technique for reducing developer frustration and confusion.

react #javascript #typescript #vue #angular