Static Structs that Mutate Data in Swift

Question

I am wondering if using static structs to mutate data in Swift is not a proper practice. I had a coding challenge for an interview and in the feedback for my work they said that "We didn't understand why you had static structs that mutated data.".

For a little background into my implementation of the coding challenge, the project was to create a clone of the iOS Calculator app. At a high level I had 3 major pieces:

1. ViewController to handle button clicks and UI formatting
2. struct handler for doing the computations
3. Custom UILabel that formatted the number for the output

Based off of posts I have read online, I always thought a struct was preferred over a class when possible because copying data is safer than having multiple reference points to a single instance.

I also decided to make the properties and functions in the class static so that I did not have to instantiate and pass around the handler in the view controller to access them. There would only ever be one handler that needed to retain data throughout the session based on the user's input.

Below is a snippet of how this handler was structured.

struct CalculationHandler {

    /// Will be the first number included in the operation
    static var firstEntry:Double?
    /// Will be the second number included in the operation
    static var secondEntry: Double?
    /// Operation that is next to be executed
    static var currentCalculation:CalculationType = .none

    /// Returns calculated value based on firstEntry, secondEntry, and CalculationType
    static func calculate(_ calculationType:CalculationType) -> Double? { ... }

This CalculationHandler was called and used in the button clicks of the ViewController, like below:

if let value = CalculationHandler.calculate(.addition) {
        outputLabel.calculatedValue = "\(value)"
}

Can anyone explain why implementing a struct with static properties/functions is not a good practice for this use-case?

Answer 1

There seems to be a major misunderstanding of why one would use a struct, a singleton, etc.

These two statements from your post contradict each other:

• First you say that you use structs "because copying data is safer than having multiple reference points to a single instance".

• Then, however, you say that you "decided to make the properties and functions in the class static so that I did not have to instantiate and pass around".

So you chose a struct to make passing data around safer and then decided to avoid passing things around altogether. Maybe that's what confused them: you used a language feature in a very untypical way.

There is not difference inbetweenusing a class or a struct when all all members are static. (Forget performance considerations, that's totally negligible in such a simple example.)

---

Coming back to your question, what they wanted to see is probably this:

struct Calculation {
  var firstNumber: Double? = nil
  var secondNumber: Double? = nil
  var type: CalculationType = .none
}

extension Calculation {
  var value: Double? {
    // ... calculate it
  }
}

That's a simple struct, just holding all the data that belongs to a calculation, plus a var to perform the calculation.

In your view controller, you would then define a didSet handler in order to update the visualization:

var calculation = Calculation() {
  didSet {
    outputLabel.calculatedValue = calculation.value
  }
}

The Swift magic that comes into play here is that whenever you reassign a member of self.calculation the didSet handler will automatically be executed (behind the scenes, a new Calculation instance is created and assigned); so in your UI handlers you only need to forward the entered data (e.g. self.calculation.firstNumber = number), which will in turn cause the output to get updated.

As I said, it's just a guess that that's what they meant with their critique. You can only know for sure when you ask ;)

Answer 2

There are plenty of reasons this isn't a great practice, but here is one main one people love to test in interviews: Does not promote composition.

Regarding composition, check out the following example:

//We could make this even more composable using generics,
//but for now this will do.
struct DoubleTuple {
   let firstNum: Double
   let secondNum: Double
}

//Again, a type alias for the return type here would make this even more composable
protocol Calculation {
   func calculate(doubleTuple: DoubleTuple) -> Double?
}

struct AdditonCalculation: Calculation {
   func calculate(doubleTuple: DoubleTuple) -> Double? {
      return doubleTuple.firstNum + doubleTuple.secondNum
   }
}

struct SubtractionCalculation: Calculation {
   func calculate(doubleTuple: DoubleTuple) -> Double? {
      let subtractTuple = DoubleTuple(firstNum: doubleTuple.firstNum, secondNum: -doubleTuple.secondNum)
      return AdditonCalculation()
                .calculate(doubleTuple: subtractTuple)
   }
}

Here, we are able to define what Subtraction means in terms of our previously defined addition struct. In other words, subtraction is composed of addition. In this example, this seems like way more work than just subtracting the two, but in more complicated calculations, it helps if you can break them down into previously-defined, composable, more simple calculations. With your example, you would presumably have a giant switch statement inside your calculate function, where the calculations could get bloated quickly, it would be harder to re-use previous calculations, and it would be harder to test each one in isolation.