The .Net frog

Une part d'un bon design orienté objet est de s'assurer que ses objets sont toujours dans un état correct.

Par exemple, dans le monde de la finance, nous avons des instruments financiers appelés "Dérivés". D'après Wikipedia:

Un produit dérivé est un instrument financier dont la valeur fluctue en fonction de l'évolution du taux ou du prix d'un produit appelé sous-jacent.

Par conséquent, dans le monde réel, un produit dérivé ne peut exister sans la présence du produit sous-jacent. Un future sur le CAC 40 n'aurait pas pu être créé sans que le CAC 40 existe auparavant. Si nous voulons représenter un produit dérivé dans une application, nous devons donc nous assurer que nous suivons la même règle.

Assumons que nous avons la classe suivante:

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;
	}
}

Un nouveau développeur arrivant sur un projet associera notre classe Derivative au concept financier associé. A priori, il n'aura pas besoin de regarder le code de la classe et il s'attendra à ce que la propriété UnderlyingInstrument retourne un objet non-null. Cependant, l'implémentation courante de le garanti pas. En réalité, cette classe peut actuellement être utilisé pour véhiculer le nom d'un dérivé sans l'associer à son produit sous-jacent. Si nous voulions faire cela, nous devrions alors créer une nouvelle classe dans ce but uniquement. En attendant, si nous voulons que notre code reste dans un état maintenable, nous devons nous assurer que chaque objet de type Derivative sera construit correctement. Sans cela, chaque personne pourra faire un usage différent et potentiellement incompatible de la classe.

Dans le cas présent, s'assurer que notre objet est dans un état correcte peut se faire très facilement. Nous devons juste appliquer une pincée de "Design By Contract". Notre constructeur deviendra alors:

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 ;
}

Maintenant, nous sommes certain qu'un collègue développeur ne va pas utiliser la classe de façon étrange :)

Évidemment, il est possible d'améliorer cet exemple de façon significative avec différents frameworks et techniques (ce qui inclus l'appel à Debug.Assert ou le développement de sa propre classe d'assertion). Par exemple, J'écrirai idéalement le code de la façon suivante:

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;
}

Mais c'est un sujet pour un autre billet!