So, let’s continue from our last post method chaining with c#!

To recap, Jim 🧔 found a cleaner, more efficient method of building his sandwich, however he’s discovered there should be a specific order to the ingredients.

With method chaining we can’t enforce a specific order of methods called. Let’s illustrate this problem.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class SandwichFactory
{

public SandwichFactory AddBread()
{
// implementation omitted for brevity
return this;
}

public SandwichFactory AddCheese()
{
// implementation omitted for brevity
return this;
}

}

We, as sandwich construction experts, want to enforce the following pattern

  • 🍞 Bread
  • 🧀 Cheese
  • 🍞 Bread

However, a consumers of our SandwichFactory class could do the following:

1
2
3
var createSandwich = new SandwichFactory()
.AddCheese()
.AddBread();

Or something worse! Let’s fix this problem.

Coming up with a nice fluent API requires a good bit of thought - Martin Fowler

Depending on the API we want to provide, complexity can rapidly escalate. For our example, we’re going to keep this small to illustrate the concepts more than application. Lets provide our solution below and go through the reasoning behind decisions made in regards to fluent interfaces:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public sealed class SandwichFactory : ISandwichBread, ISandwichCheese
{
private SandwichFactory()
{
}

public static ISandwichBread Create => new SandwichFactory();

public ISandwichCheese AddBread()
{
throw new NotImplementedException();
}

public ISandwichBread AddCheese()
{
throw new NotImplementedException();
}
}

public interface ISandwichBread
{
ISandwichCheese AddBread();
}

public interface ISandwichCheese
{
ISandwichBread AddCheese();
}
  • The constructor needs to be private - We don’t want a direct instance of our class to be created, since this would provide access to the AddBread and AddCheese methods (which is exactly what we’re trying to avoid)!
  • Static Entry point - our entry point, in this case Create should return the interface we want to start with which is ISandwichBread and an instance of our class
  • Keep parameters low - we don’t want to use tons of parameters per method, in our example we’re using 0, but it’s something to be mindful of

Consuming the SandwichFactory API, we now can’t add cheese 🧀 before bread 🍞, since our design enforces a bread > cheese hierarchy.

1
2
3
4
SandwichFactory.Create
.AddBread()
.AddCheese()
.AddBread();

Simples! 💪

Comment and share

  • page 1 of 1
Author's picture

Ash Grennan

Software engineer, mostly working with .NET, Identity, React, AWS and many other technologies.

AO.com

UK