Iterative Coding

Many software developers have found themselves working from home a lot recently. For some of us this is new, for others it is like (if you'll allow me this pun) coming home and putting on a comfortable pair of slippers. Whichever it is for you, no doubt you are finding things at least slightly more difficult at the moment.

Now, the important thing to keep in mind is that there is no shame in this. Whether you've been writing code for 30 years or you started last week, I think now is a good time for a few reminders of the hidden side of development.

Recently I've found myself using a lot of immutable classes in my code. This is great for lots of reasons, but there can be a lot of "boilerplate" code to write - particularly for classes with a lot of properties on them.

Luckily, C#9 looks set to make this much, much simpler to do with two of it's new features:

• init-only properties
• records

I'm getting this from a fantastic blog post by @MadsTorgersen which you can find here. He covers the new language features around immutability, and plenty more.

Let's take a look at how immutability looks in C# right now.

Simple Immutable Types in C#8

Right now (in C#8) if you want an immutable class it would look something like this:

public class Cat
{
  public Cat(string name, int age)
  {
    Name = name;
    Age = age;
  }

  public string Name { get; }
  public int Age { get; }
}

Now anybody can create an instance of Cat by calling the constructor, but they can't mess with any of the properties of the Cat they create. We're not quite done yet though...

"With" in C#8

That's all good, but what if you want to change the cat's name? Well, the way to do that is to create a brand new Cat with the same name and copy across all of the other properties. Something like this:

// creating our original cat
var felix = new Cat("Felix", 3);

// changing the name, but keeping the age
var penelope = new Cat("Lady Penelope", felix.Age);

We can also add this as a method to our Cat instance, to make it easier for anyone wanting to "change" a cat's name. That's where "with" comes in.

I'd like you to think back. Back to when you started developing. It doesn't have to be in any particular language, just when you started learning. If you're like me (and I hope you are, otherwise this opening is a bit of a waste), then one of the first things you'll have learnt is how to work with strings. More specifically, how you'd do this:

Console.WriteLine("What is your name?");
var name = Console.ReadLine();
Console.WriteLine("Hello, " + name + ".");

However, once you start dealing with large sets of data you want to convey in a string, things start getting funky. Below is an example of a method that takes some cats that are up for adoption, along with the currency code and the cost of each cat and returns a nice, human-readable string:

public string GenerateCatAdoptionList(IEnumerable<string> cats, char currencySymbol, double costPerCat)
{
    string catMessage = "The cats looking for loving homes are: " + cats.First();
    
    foreach (var cat in cats)
    {
        if (cat == cats.Last())
        {
            catMessage += " and " + cat + ".";    
        }
        else if (cat != cats.First())
        {
            catMessage += ", " + cat;    
        }
    }
    
    catMessage += " Our adoption fee is " + currencySymbol + costPerCat;
    
    return catMessage;
}

The Adaptor Pattern is excellent for keeping your code clean even when using messy third-party APIs.

Let's say you're using a third party library (maybe a nuget package) with the interface below:

public IHorriblePrinter
{
  // method you want to use
  int Print(string text);
  
  // methods you don't care about
  int Print(string text, bool reversed);
  int Print(string text, bool reversed, string extraText);
  
  // lots of extra methods you don't need... 
  ...
}

And you have some code using this interface:

IHorriblePrinter printer = ...
printer.Print("Some words I want to print!");

The problem here is that your code now depends on the IHorriblePrinter interface. This is annoying for a few reasons:

• the IHorribleInterface interface is difficult to work with. If anyone wanted to implement the interface they have to write code for all of the useless methods, not just the method we actually use.
• it's not clear which method we use. From an outside perspective our code depends on everything in the IHorriblePrinter interface.
• it's difficult to write tests for our code. We would have to mock IHorriblePrinter and wouldn't know which methods we need to mock.
• anyone working on the code can easily start using the other methods on IHorriblePrinter and it's hard to keep track of which parts of the interface we actually care about.
• the IHorriblePrinter.Print(string text) method that we want to use returns an int which we really don't want.

The first step to solving this is to write the interface we wish we were working with. In this case that's quite simple:

public interface INicePrinter
{
  void Print(string text);
}

Now we have a nice interface we can change our code to use this interface we need a way of using it. That's where the adaptor comes in:

public class HorriblePrinterAdaptor : INicePrinter
{
  public HorriblePrinterAdaptor(IHorriblePrinter horrible)
  {
    _horrible = horrible
      ?? throw new ArgumentNullException(nameof(horrible));
  }

  public void Print(string text)
  {
    _horrible.Print(text);
  }
}