I know the title might catch a few people off guard, but let me explain. Side effecting functions, for the most part, are code smells. This is a very important concept in
Domain Driven Design (DDD) that's often overlooked. For those who are deep in DDD, this should sound rather familiar. And in the end, I think
Spec# and some
Design by Contract (DbC) constructs can mitigate this, or you can go the functional route as well.
What Is A Side Effect?
When you think of the word side effect in most languages, you tend to think of any unintended consequence. Instead, what we mean by it is having any effect on the system from an outside force. What do I mean by that? Well, think of these scenarios, reading and writing to a database, reading or writing to the console, or even modifying the state of your current object. Haskell and other functional languages take a pretty dim view of side effects, hence why they are not allowed, unless through monads. F# also takes this stance, as "variables" are immutable unless otherwise specified.
Why Is It A Smell?
Well, let's look at it this way. Most of our operations call other operations which call even more operations. This deep nesting is then created. From this deep nesting, it becomes quite difficult to predict the behaviors and consequences of calling all of those nested operations. You, the developer might not have intended for all of those operations to occur because A modified B modified C modified D. Without any safe form of abstraction, it's pretty hard to test as well. Imagine that any mock objects that you create would have to suddenly know in 5 levels deep that it is modified in some function. Not necessarily the best thing to do.
Also, when it comes to multi-threaded processing, this becomes even more of an issue. If multiple threads have a reference to the same mutable object, and one thread changes something on the reference, then all other threads were just side effected. This may not be something that you'd want to do. Then again, if working on shared memory applications, that might be. But, for the most part, the unpredictability of it can be a bad thing.
Let's take a quick example of a side effecting an object like implementation of a 2 dimensional Point. We're going to go ahead and allow ourselves to add another Point to the system.
public class Point2D
{
public double X { get; set; }
public double Y { get; set; }
public void Add(Size2D other)
{
X += other.Height;
Y += other.Width;
}
}
public class Size2D
{
public double Height { get; set; }
public double Width { get; set; }
}
What's wrong with the above sample is that I just side effected the X, and Y. Why is this bad? Well, like I said, most objects like these are fire and forget. Anyone who had a reference to this Point now has a side effected one, that they might not have wanted. Instead, I should probably focus on retrieving a new one at this point, since this is pretty much a value object.
What Can You Do About It?
Operations that return results without side effects are considered to be pure functions. These pure functions when called any number of times will return the same result given the same parameters time and time again. Pure functions are much easier to unit test and overall a pretty low risk.
There are several approaches to being able to fix the above samples. First, you can keep your modifiers and queries separated. Make sure you keep the methods that make changes to your object separate from those that return your domain data. Perform those queries and associated calculations in methods that don't change your object state in any way. So, think of a method that calculates price and then another method that actually sets the price on the particular object.
Secondly, you could also just not modify the object at all. Instead, you could return a value object that is created as an answer to a calculation or a query. Since value objects are immutable, you can feel free to hand them off and forget about them, unlike entities which are entirely mutable. Let's take the above example of the Coordinate and switch it around. Think of the DateTime structure. When you want to add x number of minutes, do you side effect the DateTime, or do you get a new one? The answer is, you get a new one? Why, well, because it's a structure, and they are immutable, but not only that, it solves a lot of those side effecting problems.
public class Point2D
{
private readonly double x;
private readonly double y;
public Point2D() {}
public Point2D(double x, double y)
{
this.x = x;
this.y = y;
}
public double X { get { return x; } }
public double Y { get { return y; } }
public Point2D Add(Size2D other)
{
double newX = x + other.Height;
double newY = y + other.Width;
return new Point2D(newX, newY);
}
}
Spec# is a tool that can help in this matter.
Previously I stated why Spec# matters, well, let's get into more detail why. We can mark our side effect free methods as being pure with the [Pure] attribute. This allows the system to verify that indeed we are not side-effecting the system, and any time I call that with the same parameters, I will get the same result. It's an extra insurance policy that makes it well known to the caller that I'm not going to side effect myself when you call me. So, let's go ahead and add some Spec# goodness to the equation.
[Pure]
public Point2D Add(Size2D other)
{
double newX = x + other.Height;
double newY = y + other.Width;
return new Point2D(newX, newY);
}
But, now Spec# will warn us that our other might be null, and that could be bad.... So, let's fix that to add some real constraints for the preconditions.
[Pure]
public Point2D Add(Size2D other)
requires other != null
{
double newX = x + other.Height;
double newY = y + other.Width;
return new Point2D(newX, newY);
}
Of course I could have put some ensures as well to ensure the result will be the addition, but you get the point.
Turning To Design by Contract
Now of course we have to be a pragmatist about things. At no point did I say that we can't have side effects ever. That would be Haskell and they put themselves into a nasty corner with that and the only way around it was with monads, that can be a bit clumsy. Instead, I want to refocus where we do them and be more aware of what you're modifying.
In our previous examples, we cut down on the number of places where we had our side effects. But, this does not eliminate them, instead gather them in the appropriate places. Now when we deal with entities, they are very much mutable, and so we need to be aware when and how side effects get introduced. To really get to the heart of the matter, we need to verify the preconditions, the postconditions and mostly our invariants. In a traditional application written in C#, we could throw all sorts of assertions into our code to make sure that we are in fact conforming to our contract. Or we can write our unit tests to ensure that they conform to them. This is an important point in Eric Evans' book when talking about assertions in the Supple Design chapter.
Once again, Spec# enters again as a possible savior to our issue. This allows us in our code, to model our preconditions and our postconditions as part of our method signature. Invariants as well can be modeled as well into our code as well. These ideas came from Eiffel but are very powerful when used for good.
Let's make a quick example to show how invariants and preconditions and postconditions work. Let's create an inventory class, and keep in mind it's just a sample and not anything I'd ever use, but it proves a point. So let's lay out the inventory class and we'll set some constraints. First, we'll have the number of items remaining. That number of course can never go below zero. Therefore, we need an invariant that enforces that. Also, when we remove items from the inventory, we need to make sure that we're not going to dip below zero. Very important things to keep in mind.
public class Inventory
{
private int itemsRemaining;
private int reorderPoint;
invariant itemsRemaining >= 0;
public Inventory()
{
itemsRemaining = 200;
reorderPoint = 50;
base();
}
public void RemoveItems(int items)
requires items <= ItemsRemaining;
ensures ItemsRemaining == old(ItemsRemaining) - items;
{
expose(this)
{
itemsRemaining -= items;
}
// Check reorder point
}
public int ItemsRemaining { get { return itemsRemaining; } }
// More stuff here in class
}
What I was able to express is that I set up my invariants in the constructor. You cannot continue in a Spec# program unless you set the member variable that's included in the invariant. Also, look at the RemoveItems method. We set one precondition that states that number of items requested must be less than or equal to the number left. And we set the postcondition which states that the items remaining must be the difference between the old items remaining and the items requested. Pretty simple, yet powerful. We had to expose our invariant while modifying it so that it could be verified, however. But, doesn't it feel good to get rid of unit tests that prove what I already did in my method signature?
Wrapping Things Up
So, I hope after reading this, you've thought more about your design, and where you are modifying state and that you have intention revealing interfaces to tell the coder what exactly you are going to do. The Design by Contract features of Spec# also play a role in this to state in no uncertain terms what exactly the method can do with the preconditions and postconditions and through my class with my invariants. Of course you can use your regular C#, or language of choice to model the same kind of things, yet not as intention revealing.
So, where to go from here? Well, if you've found Spec# interesting, let Microsoft know about it. Join the campaign that Greg and I are harping on and say,
"I Want Spec#!"
