Implement the strategy pattern with delegates
Changing the default behavior of a method under testing (or any other specific circumstance)
Given the following code:
class EmailSender{
public void Send (string recipient, string subject, string body) {//invoke 3rd party}
}
class Email{
public EmailSender _sender = new EmailSender();
public Send(){_sender.Send(recipient, subject, body);}
}
Imagine that you cannot change the Email class. How would you unit test it without making a call to a 3rd party service?
Answer: inject a delegate with the desired behavior.
class EmailSender{
Action<string,string,string> _sendAction = _send; //default action
public void Send (string recipient, string subject, string body) {
_send.Invoke(recipient, subject, body);
}
public void _send (string recipient, string subject, string body) {//invoke 3rd party}
internal void ActivateTestMode( Action<string,string,string> testAction){
_send = testAction;
}
}
Specializing the rules of a domain object without inheritance
Given the following code:
public class BonusCalculator()
{
List<Bonus> bonuses = new List<Bonus>();
public BonusCalculator(ICollection<Bonus> bonus)
{
bonuses.AddRange(bonus);
}
public decimal CalcBonus(Vendor vendor)
{
var amount = 0;
bonuses.foreach(bonus=>amount += bonus.Invoke(vendor, amount));
return amount;
}
}
public class BonusCalculatorFactory()
{
public BonusCalculator GetSouthernBonusCalculator()
{
var bonuses = new List<Bonus>();
bonuses.Add(new WashMachineSellingBonus());
bonuses.Add(new BlenderSellingBonus ());
bonuses.Add(new StoveSellingBonus ());
return new BonusCalculator(bonuses);
}
}
If we want to add a new bonus that increments the 15% we would have to create a new class just to do that multiplication… So let’s try something different.
public class BonusCalculator()
{
List<Func<Vendor, Decimal>> bonuses = new List<Func<Vendor, Decimal>>();
public BonusCalculator(ICollection<Bonus> bonus)
{
bonuses.AddRange(bonus);
}
public decimal CalcBonus(Vendor vendor)
{
var amount = 0;
bonuses.foreach(bonus=>amount += bonus.Apply(vendor, amount));
return amount;
}
}
Now we have to modify the factory
public class BonusCalculatorFactory()
{
public BonusCalculator GetSouthernBonusCalculator()
{
var bonuses = new List();
bonuses.Add(new WashMachineSellingBonus().Apply);
bonuses.Add(new BlenderSellingBonus().Apply);
bonuses.Add(new StoveSellingBonus().Apply);
bonuses.Add((vendor,amount)=> amount * 1.15);
return new BonusCalculator(bonuses);
}
}
Easy peasy. Now depending on how it is implemented, we could start thinking about turning some of the rules into singletons.
Moving the control flow into objects
How many times have you started an operation where you want to know 1) if the operation was successful and 2) the return value. A lot of times this leads to code like:
class OperationResult{
public bool IsSuccess{get;set;}
public object ResultValue {get;set;}
}
interface IDataGateway{
OperationResult UpdateName(string name);
}
class NameUpdaterCommand{
string _name;
IDataGateway _data;
Log _log;
public NameUpdaterCommand(string name, IDataGateway data, Log log){
_data = data;
_name = name;
_log = log;
}
public void Execute(){
var result = _data.UpdateName(_name);
if(result.IsSuccess)
_log.Write("Name updated to:" + Result.Value.ToString());
else
_log.Write("Something went wrong:" + + Result.Value.ToString());
}
}
Come on, don’t be shy about it. I’ve done it myself too…
So what’s wrong with it?
Let’s see, the intention behind this code it’s to decide on a course of action based on the result of an operation. In order to carry on these actions, we need some additional info for each situation. A problem with this code is that you can’t handle an additional scenario. For that to happen instead of a boolean IsSuccess you would have to create an enumerator of sorts. Like:
enum ResultEnum{
FullNameUpdated,
FirstNameUpdated,
UpdateFailed
}
class OperationResult{
public ResultEnum Result {get;set;}
public object ResultValue {get;set;}
}
interface IDataGateway{
OperationResult UpdateName(string name);
}
class NameUpdaterCommand{
string _name;
IDataGateway _data;
Log _log;
public NameUpdaterCommand(string name, IDataGateway data, Log log){
_data = data;
_name = name;
_log = log;
}
public void Execute(){
var result = _data.UpdateName(_name);
switch(result.Result){
case ResultEnum.FullNameUpdated:
_log.Write("Full name updated to:" + Result.Value.ToString());
break;
case ResultEnum.FirstNameUpdated:
_log.Write("First name updated to:" + Result.Value.ToString());
break;
case ResultEnum.UpdateFailed:
_log.Write("Something went wrong:" + + Result.Value.ToString());
break;
}
}
}
So now every time you want to add a new scenario you have to add a new enum value and a new case on the switch. This is more flexible than before but a little more laborious than it should be. Let’s try to replace this enum based code with objects that represent each case:
interface IDataGateway{
void UpdateName(string name, Action<string> firstNameUpdated, Action<string> fullNameUpdated, Action<string> updateFailed);
}
class NameUpdaterCommand{
string _name;
IDataGateway _data;
Log _log;
public NameUpdaterCommand(string name, IDataGateway data, Log log){
_data = data;
_name = name;
_log = log;
}
public void Execute(){
_data.UpdateName(_name,
fullNameUpdated: name => _log.Write("Full name updated to: " + name),
firstNameUpdated: name => _log.Write("First name updated to: " + name),
updateFailed: error => _log.Write("Something went wrong: " + error )
);
}
}
So now we have a shorter code. We have also moved the responsibility to control the flow to the object implementing IDataGateway. How it does it is just an implementation detail. We don’t care if it’s using an enumerator or any other mechanism as long as it works.
Phew! I think that’s enough for now. Now go improve your code!
