The .Net frog

Part of a good object oriented design is to keep the objects in a correct state.

For instance, in the financial world, we have financial instruments called "derivatives". According to Wikipedia:

Derivatives are financial instruments whose value changes in response to the changes in underlying variables. The main types of derivatives are futures, forwards, options, and swaps.

In the real world, a derivative can't exist if there isn't an underlying financial instrument associated. A future on the dow jones could not have been created without the dow jones in the first place. If we want to represent a derivative in a software, we must make sure that we follow the same rule.

So let's assume that I have the following class:

class Derivative
{
	private string _name;
	private Instrument _underlyingInstrument ;
 
	public string Name
	{
		get { return _name; }
	}
 
	public Instrument UnderlyingInstrument
	{
		get { return _underlyingInstrument; }
	}
 
	public Derivative(string name, Instrument underlyingInstrument)
	{
		_name = name;
		_underlyingInstrument = underlyingInstrument;
	}
}

Any new developer on a project that uses this Derivative class will mentally map the Derivative class to the corresponding financial concept. He will expect the UnderlyingInstrument property to return a non-null object. However, this is not guaranteed in the current implementation. As a matter of fact, this class can currently be used to only convey the name of a Derivative. If we wanted to do that, we would need to create a new class for that purpose only. So in the mean time, if we want our code to stay in a maintainable state, we need to make sure that each Derivative object will be constructed correctly. If not, different people will make different usage of the class.

In that case, ensuring the correctness of the object can be done very easily. We just need to do a bit of Design By Contract. So our constructor will become:

public Derivative(string name, Instrument underlyingInstrument)
{
	if(name == null || name.Length == 0)
	{
		throw new Exception("The name of the derivative can't be null or empty");
	}
	else if(underlyingInstrument == null)
	{
		throw new Exception("A derivative must have an underlying instrument");
	}
 
        _name = name;
        _underlyingInstrument = underlyingInstrument ;
}

Now you're sure that a fellow developer won't use your object to do a weird thing :).

Of course, you can improve the clarity of this piece of code significantly by using various techniques and frameworks(including Debug.Assert or your own Assert class). For instance, I would write something like that:

public Derivative(string name, Instrument underlyingInstrument )
{
	Guard.Against(name == null, "The name of the derivative can't be null");
	Guard.Against(name.Length == 0, "The name of the derivative can't be empty");
	Guard.Against(underlyingInstrument == null, "The underlying instrument of the derivative can't be null");
 
	_name = name;
	_underlyingInstrument = underlyingInstrument;
}

But that's a topic for another day!