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.
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:
var createSandwich = new SandwichFactory()
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:
public sealed class SandwichFactory : ISandwichBread, ISandwichCheese
- 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
AddCheesemethods (which is exactly what we’re trying to avoid)!
- Static Entry point - our entry point, in this case
Createshould return the interface we want to start with which is
ISandwichBreadand 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
SandwichFactory API, we now can’t add cheese 🧀 before bread 🍞, since our design enforces a bread > cheese hierarchy.