Tag-Archive for ◊ Refactoring ◊

Refactoring out parameters code smell to Tuple
Author:
Tuesday, October 09th, 2012
Using out parameters in methods are usually a code smell with indicates that you want to effectively return two results from a method. Out parameters are mostly introduced when developers realize the need of an additional return value from an already existing method. The problem with out parameters is that they introduce the risk of side effects and are hard to debug.
You can use the Transform out parameters refactoring to transform out parameters to a tuple in C#. Later you can convert the tuple with a class or struct with a static create method to enhance readability and maintainability.
For e.g., we can refactor the below given code
[TestMethod]
public void AddEmployeeReturnsTrueIfEmployeeWasSaved()
{
var employee = new Employee {Name = “Prajeesh Prathap”};
var repository = new EmployeeRepository();
int employeeId = 0;
var success = repository.Add(employee, out employeeId);
Assert.IsTrue(success);
repository.RemoveAll();
}
public bool Add(Employee employee, out int employeeId)
{
employeeId = 0;
if (_employees.Any(x => x.Name == employee.Name)) return false;
employee.Id = _employees.Any() ? _employees.Max(x => x.Id) + 1 : 1;
employeeId = employee.Id;
_employees.Add(employee);
return true;
}

Using the transform out parameters refactoring pattern to…
[TestMethod]
public void AddEmployeeReturnsTrueIfEmployeeWasSaved()
{
var employee = new Employee {Name = “Prajeesh Prathap”};
var repository = new EmployeeRepository();
var add = repository.Add(employee);
var success = add.Item1;
Assert.IsTrue(success);
repository.RemoveAll();
}
public Tuple<bool, int> Add(Employee employee)
{
int employeeId = 0;
if (_employees.Any(x => x.Name == employee.Name)) return Tuple.Create(false, employeeId);
employee.Id = _employees.Any() ? _employees.Max(x => x.Id) + 1 : 1;
employeeId = employee.Id;
_employees.Add(employee);
return Tuple.Create(true, employeeId);
}

Further improvement can be achieved by encapsulating the parameters in a class as given below
public class AddOutput
{
public bool Result { get; set; }
public int Id { get; set; }
public static AddOutput Create(bool success, int id)
{
return new AddOutput {Result = success, Id = id};
}
}
public AddOutput Add(Employee employee)
{
int employeeId = 0;
if (_employees.Any(x => x.Name == employee.Name)) return AddOutput.Create(false, employeeId);
employee.Id = _employees.Any() ? _employees.Max(x => x.Id) + 1 : 1;
employeeId = employee.Id;
_employees.Add(employee);
return AddOutput.Create(true, employeeId);
}
[TestMethod]
public void AddEmployeeReturnsTrueIfEmployeeWasSaved()
{
var employee = new Employee {Name = “Prajeesh Prathap”};
var repository = new EmployeeRepository();
var add = repository.Add(employee);
var success = add.Result;
Assert.IsTrue(success);
repository.RemoveAll();
}
Category: .Net, Agile/Scrum | Tags:  | Leave a Comment
Refactoring to Maybe pattern
Author:
Saturday, September 22nd, 2012

The NullReferenceException is the most commonly occurring bugs in any programming language.

Passing nulls from a method leaves the responsibility to check the validity of the response object to the callee object/ method which leaves the space of null reference exceptions. For example in the code given below, the method which calls the repository’s GetById method needs to make sure that the Customer object is a valid one before making the assertions.
[TestMethod]
public void GetCustomerReturnsCustomerWithIDFromDB()
{
var repository = new CustomerRepository(_dbContext);
const int customerId = 5;
var customer = repository.GetById(customerId);
if(customer != null) Assert.AreEqual(customer.Id, 5);
Assert.Inconclusive(string.Format(“Customer with Id {0} was not found in the context”, 5));
}
public Customer GetById(int id)
{
return _context.Customers.FirstOrDefault(x => x.Id == id);
}
Refactoring the code to a maybe pattern implementation will make the repository define the contract of GetById to return a Maybe object which the callee always expects.
public interface Maybe<out T>
{
bool HasValue { get; }
T Value { get; }
}
public class Some : Maybe where T : class
{
private T _value;
public Some(T value)
{
_value = value;
}
public bool HasValue { get { return true; } }
public T Value { get { return _value; } }
}
public class None : Maybe where T : class
{
public bool HasValue { get { return false; } }
public T Value { get { throw new MaybeException();} }
}
The GetById method signature now changes to
public Maybe<Customer> GetById(int id)
{
var customer = _context.Customers.FirstOrDefault(x => x.Id == id);
return customer == null ? new None<Customer>() : new Some<Customer>(customer) as Maybe<Customer>;
}
Category: PHP | Tags: ,  | Leave a Comment
Refactoring implicit language elements to form interpreters
Author:
Sunday, September 09th, 2012

In business applications, while creating searching algorithms you need to create a search context which consists of a combination of multiple algebraic expressions. A simple example is given below where the filter for searching books is created by combining multiple expressions as in the code sample below.

[TestMethod]
public void GetAllBooksInRangeByTopicShouldReturnAllBooksInThePriceRangeFilteredByTopic()
{
var amazonService = new BookStore();
const decimal fromRange = 50;
const decimal toRange = 100;
const string genre = “Travel Guide”;
var books = amazonService.GetBooksByPriceRangeAndGenre(fromRange, toRange, genre);
Assert.IsTrue(books.Any());
}
public IEnumerable<Book> GetBooksByPriceRangeAndGenre(decimal from, decimal to, string genre)
{
return GetAll().Where(x => x.Genre.Name.ToLower().Contains(genre.Trim().ToLower())
&& (x.Price >= from && x.Price <= to));
}
We can refactor these expressions to a more readable and maintainable structure by creating specifications using the interpreter pattern as given below.
public IEnumerable<Book> GetBooksByPriceRangeAndGenre(decimal from, decimal to, string genre)
{
var bookSpec = GetBookSpec(genre, from, to);
return GetAll().Where(bookSpec.SatisfiedBy());
}
private BookSpecification GetBookSpec(string genre, decimal from, decimal to)
{
return new BookSpecification(from, to, genre);
}
public class BookSpecification : ISpecification<Book>
{
private readonly decimal _from;
private readonly decimal _to;
private readonly string _genre;
public BookSpecification(decimal from, decimal to, string genre)
{
_from = from;
_to = to;
_genre = genre;
}
public Expression<Func<Book, bool>> SatisfiedBy()
{
return new GenreSpecification(_genre).AND(new PriceRangeSpecification(_from, _to)).SatisfiedBy();
}
}
public class GenreSpecification : ISpecification<Book>
{
private readonly string _genre;
public GenreSpecification(string genre)
{
_genre = genre.Trim().ToLower();
}
public Expression<Func<Book, bool>> SatisfiedBy()
{
return new Specification<Book>(x => x.Genre.Name.ToLower().Contains(_genre)).SatisfiedBy();
}
}
public class PriceRangeSpecification : ISpecification<Book>
{
private readonly decimal _from;
private readonly decimal _to;
public PriceRangeSpecification(decimal from, decimal to)
{
_from = from;
_to = to;
}
public Expression<Func<Book, bool>> SatisfiedBy()
{
return new Specification<Book>(x => x.Price >= _from && x.Price <= _to).SatisfiedBy();
}

}

Category: .Net, Agile/Scrum | Tags: ,  | 2 Comments
Introduce Assertion refactoring using Code contracts
Author:
Sunday, August 26th, 2012
Code Contracts provide a language-agnostic way to express coding assumptions in .NET programs by offering a number of attributes and helper classes to help formalize any assumptions you make in your code into a contract. A contract can pertain to pre-conditions, post-conditions, assumptions and “object invariants” that enable static contract verification and runtime checking of values.
The Introduce Assertion refactoring recommends making an assumption explicit with an assertion if a section of code is going to make that assumption about the state of the program. You can use code contracts to implement this refactoring in your code. In this post, we’ll see how to refactor your code to add code contracts for assumptions.
[TestMethod]
public void TransferDepositsRequestedAmountInTheAccountFromTheCurrentAccount()
{
var account = new Account(300);
var accountToTransfer = new Account();
account.Transfer(accountToTransfer, 150);
Assert.AreEqual(account.GetBalance(), 150);
}
public decimal Transfer(Account account, decimal amount)
{
_accountBalance -= amount;
account.Deposit(amount);
return _accountBalance;
}
The code given assumes that the client that calls the transfer method on the current account object passes a valid account object to the transfer method to do the transfer.
We can prevent the object from being instable by adding assert assumptions as given below.
[TestMethod]
[ExpectedException(typeof(AssertFailedException))]
public void TransferDepositsRequestedAmountInTheAccountFromTheCurrentAccount()
{
var account = new Account(300);
var accountToTransfer = default(Account);
account.Transfer(accountToTransfer, 150);
Assert.AreEqual(account.GetBalance(), 150);
}
public decimal Transfer(Account account, decimal amount)
{
Assert.IsNotNull(account);
_accountBalance -= amount;
account.Deposit(amount);
return _accountBalance;
}
Apart from checking that account should not be null, we need to make further assumptions or verification on the code before we do the actual transfer. We need to make sure that the account has the required balance before transferring the amount to the other account. Also after the transfer the account should have a minimum balance according to the requirements.
Let’s see how code contracts can be used to add the required assumptions and verifications on the code.
[TestMethod, ExpectContractFailure]
public void TransferDepositsRequestedAmountInTheAccountFromTheCurrentAccount()
{
var account = new Account(300);
var accountToTransfer = new Account();
account.Transfer(accountToTransfer, 300);
Assert.AreEqual(account.GetBalance(), 50);
}
public decimal Transfer(Account account, decimal
amount)
{
Contract.Requires(account != null);
Contract.Ensures(Contract.Result<decimal>() >= _minimumBalance);
Contract.Assume(amount < _accountBalance);
_accountBalance -= amount;
account.Deposit(amount);
return _accountBalance;
}
The ExpectContractFailure attribute is a custom attribute created to assert the ContactFailed exception.
public class ExpectContractFailureAttribute : ExpectedExceptionBaseAttribute
{
const string ContractExceptionName = “System.Diagnostics.Contracts.__ContractsRuntime+ContractException”;
protected override void Verify(Exception exception)
{
if (exception.GetType().FullName != ContractExceptionName)
{
RethrowIfAssertException(exception);
throw new ArgumentException(“Exception {0} as found instead of contract exception.”,
exception.GetType().FullName);
}
}
}
Category: .Net, Agile/Scrum | Tags:  | 3 Comments
Resharper series – Extracting factory classes
Author:
Tuesday, June 28th, 2011

You may have come across code that creates a new instance of an object and setting it to a default state before working on it. Sometimes however the creation requirements of this object may grow and clouds the original code that was used to create the object. This is where a Factory class comes into play. For e.g. have a look into the below given test cases and classes.

[TestMethod]
public void ZoomLensesCanHaveMacroModeAlso()
{
const string lensDescription = “Canon EF-S 55-250mm f/4.0-5.6 IS Telephoto Zoom Lens”;
var zoomLens = new ZoomLens(lensDescription);
zoomLens.SetCloseupConversion(true);
Assert.IsTrue(zoomLens.HasMacroMode());
}
[TestMethod]
public void WideAngleLensesHaveUltraWideView()
{
const string lensDesription = “Canon EF 35mm f/2 Wide Angle Lens”;
var wideAngleLens = new WideAngleLens(lensDesription);
wideAngleLens.SetUltraWideView(true);
Assert.IsTrue(wideAngleLens.HasUltraWideView());
}
The classes used in the sample are as given below.
public class ZoomLens
{
private readonly string _lensDescription;
private bool _closeUpConversionEnabled;
public ZoomLens(string lensDescription)
{
_lensDescription = lensDescription;
_closeUpConversionEnabled = false;
}
public void SetCloseupConversion(bool closeUpConversion)
{
_closeUpConversionEnabled = closeUpConversion;
}
public bool HasMacroMode()
{
return _closeUpConversionEnabled;
}
}
public class WideAngleLens
{
private readonly string _lensDesription;
private bool _enableUltraWideView;
public WideAngleLens(string lensDesription)
{
_lensDesription = lensDesription;
_enableUltraWideView = false;
}
public void SetUltraWideView(bool enableUltraWideView)
{
_enableUltraWideView = enableUltraWideView;
}
public bool HasUltraWideView()
{
return _enableUltraWideView;
}
}
As you can see from the classes used in the sample, I can implement a class hierarchy by creating a superclass or an interface for the camera lenses and move the common methods to that type and make the subclasses implement/ inherit the superclass. This provides the situation for usage of a Factory method that makes it easy for programmers to extend the functionality of the framework by introducing polymorphic creations of objects.
First we need to extract all common methods and properties of these classes to a common base class. I have used the Extract Superclass refactoring to create a superclass for the classes in this sample.
After extracting the superclass, we need to create the constructor for the base class with the common properties.
public class CameraLens
{
protected string _lensDesription;
public CameraLens(string lensDescription)
{
_lensDesription = lensDescription;
}
}
Refactor the base class to use this constructor during object creation.
public WideAngleLens(string lensDesription) : base(lensDesription)
{
_enableUltraWideView = false;
}
Use the Pull members refactoring to move the methods as abstract to the parent class.
Repeat the steps for other inheriting classes also. Compile and run the test cases.
Next use the Extract Method refactoring to move the creation logic to creation methods in the test cases.
After applying the refactoring pattern the code looks like
public void ZoomLensesCanHaveMacroModeAlso()
{
const string lensDescription = “Canon EF-S 55-250mm f/4.0-5.6 IS Telephoto Zoom Lens”;
CameraLens zoomLens = CreateCameraLens(lensDescription);
zoomLens.SetCloseupConversion(true);
Assert.IsTrue(zoomLens.HasMacroMode());
}
private static CameraLens CreateCameraLens(string lensDescription)
{
return new ZoomLens(lensDescription);
}
Use the Move to another type refactoring pattern and specify the name of the new class in the type as given below
Make the Create method non- static and use the Extract Interface refactoring as given below.
Now you can use this interface as a dependency for your client classes that needs to create the Camera lenses or change the test cases as given below
private ICameraLensFactory _zoomCameraLensFactory;
[TestInitialize]
public void Initialize()
{
_zoomCameraLensFactory = new ZoomCameraLensFactory();
}
[TestMethod]
public void ZoomLensesCanHaveMacroModeAlso()
{
const string lensDescription = “Canon EF-S 55-250mm f/4.0-5.6 IS Telephoto Zoom Lens”;
var zoomLens = _zoomCameraLensFactory.CreateCameraLens(lensDescription);
zoomLens.SetCloseupConversion(true);
Assert.IsTrue(zoomLens.HasMacroMode());
}
Category: .Net, Agile/Scrum, General | Tags: , ,  | Leave a Comment
Resharper series – Replacing conditional logic with strategies
Author:
Tuesday, June 21st, 2011
When you have a method with lots of conditional logic (i.e., if statements), you’re asking for trouble. Conditional logic is notoriously difficult to manage, and may cause you to create an entire state machine inside a single method. In such a situation, it is better to move each algorithm variation to new classes or to subclasses of the host class. The ideal solution would be to replace these conditional statements with a strategy implementation and delegate the execution to the concrete strategy implementations.
For e.g consider the test code and Calculator implementation given below. The execute methods runs a different algorithm based on the operator chosen.
[TestMethod()]
public void ExecuteMethodShouldCalculateTheSumIfOperationSelectedIsAddition()
{
var calculator = new Calculator();
calculator.SetOperation(Operator.Add);
var result = calculator.Execute(3, 5);
Assert.IsTrue(result == 8);
}
[TestMethod]
public void ExecuteMethodShouldCalculateTheDifferenceIfOperationSelectedIsSubtraction()
{
var calculator = new Calculator();
calculator.SetOperation(Operator.Subtract);
var result = calculator.Execute(3, 5);
Assert.IsTrue(result == -2);
}
[TestMethod]
public void ExecuteMethodShouldCalculateTheMultipledResultIfOperationSelectedIsMultiplication()
{
var calculator = new Calculator();
calculator.SetOperation(Operator.Multiply);
var result = calculator.Execute(3, 5);
Assert.IsTrue(result == 15);
}
[TestMethod]
public void ExecuteMethodShouldCalculateTheDivisionResultIfOperationSelectedIsDivision()
{
var calculator = new Calculator();
calculator.SetOperation(Operator.Divide);
var result = calculator.Execute(15, 5);
Assert.IsTrue(result == 3);
}
public class Calculator
{
private Operator _operator;
public void SetOperation(Operator operation)
{
this._operator = operation;
}
public int Execute(int firstArgument, int secondArgument)
{
if(_operator == Operator.Add)
return firstArgument + secondArgument;
if (_operator == Operator.Subtract)
return firstArgument – secondArgument;
if(_operator == Operator.Multiply)
return firstArgument * secondArgument;
if (_operator == Operator.Divide)
{
if (secondArgument != 0)
return firstArgument / secondArgument;
else
throw new ArgumentException(“Divider cannot be zero”);
}
return 0;
}
}
public enum Operator
{
Add,
Subtract,
Multiply,
Divide
}
  • As a first step to refactoring this code, we use the Extract Method to extract the logic to separate methods as given below.
  • Once you have completed all the extractions the code now looks like.
public int Execute(int firstArgument, int secondArgument)
{
if(_operator == Operator.Add)
return PerformAdd(firstArgument, secondArgument);
if (_operator == Operator.Subtract)
return PerformSubtraction(firstArgument, secondArgument);
if(_operator == Operator.Multiply)
return PerformMultiplication(firstArgument, secondArgument);
if (_operator == Operator.Divide)
return PerformDivision(firstArgument, secondArgument);
return 0;
}
private int PerformDivision(int firstArgument, int secondArgument)
{
if (secondArgument != 0)
return firstArgument / secondArgument;
else
throw new ArgumentException(“Divider cannot be zero”);
}
private int PerformMultiplication(int firstArgument, int secondArgument)
{
return firstArgument * secondArgument;
}
private int PerformSubtraction(int firstArgument, int secondArgument)
{
return firstArgument – secondArgument;
}
private int PerformAdd(int firstArgument, int secondArgument)
{
return firstArgument + secondArgument;
}
  • Next we use the ‘Move to another type’ refactoring to move these methods to separate classes, which we’ll make as concrete strategy implementations later.
  • After this refactoring your code looks like
public class Calculator
{
private Operator _operator;
public void SetOperation(Operator operation)
{
this._operator = operation;
}
public int Execute(int firstArgument, int secondArgument)
{
if(_operator == Operator.Add)
return AdditionStrategy.PerformAdd(firstArgument, secondArgument);
if (_operator == Operator.Subtract)
return SubtractionStrategy.PerformSubtraction(firstArgument, secondArgument);
if(_operator == Operator.Multiply)
return MultiplicationStrategy.PerformMultiplication(firstArgument, secondArgument);
if (_operator == Operator.Divide)
return DivisionStrategy.PerformDivision(firstArgument, secondArgument);
return 0;
}
}
  • Use the ‘Rename’ refactoring to change the name of PerformAdd, PerformSubtraction.. methods to Execute.
  • After renaming we’ll use the ‘Extract Superclass’ refactoring to create a superclass for these Strategies.
  • Now create an abstract method Execute with the same signature as in the base classes in the newly created superclass.
  • Use the resharper intellisense to make the superclass abstract.
  • Now move to the subclasses and make the execute method override, using the resharper menu.
  • Finally create a new Factory implementation to create concrete instances for these strategies based on the parameter passed and use this in the Calculator class as given below.
public int Execute(int firstArgument, int secondArgument)
{
var operationStrategyFactory = new OperationStrategyFactory(_operator);
var operationStrategy = operationStrategyFactory.Create();
return operationStrategy.Execute(firstArgument, secondArgument);
}
Category: .Net, Agile/Scrum, General | Tags: , , ,  | Leave a Comment
Resharper series – Replacing constructors with creation methods
Author:
Monday, June 20th, 2011
Replacing your constructors with creational methods or static factories helps to reduce cumbersome code with multiple overloaded constructors in the class and clients having confusion which one to invoke and how. The overloaded constructors in your code creates confusion in the mind of a fellow programmer when he wants to create a new instance of the object, the main problem with these constructors are that they cannot be renamed to give a meaningful name. One of the easiest ways to address this problem is to use creation methods or static factories.
Creation methods have better readability and by having meaningful names so that the consumer gets a clear idea of each method and when to use them. Let’s see how we can use refactoring to remove overloaded constructors in the code and replace them with creation methods.
  • As a first step of refactoring find the client code that calls the constructor to create an instance of the type.
[TestMethod]
public void AllDucksCanSwimTest()
{
var pool = new Pool(_ducks);
Assert.IsTrue(pool.CanAllDucksSwim());
}
  • In the above test method I have a constructor for instantiating the Pool object, which we can refactor to create a new creation method.
  • Use the Extract method refactoring to create a new static method to get the Pool instance
  • Now use the Move to another Type refactoring to move the method to the Pool class.
public class Pool
{
private readonly IList<Duck> _ducks;
public Pool(IList<Duck> ducks)
{
_ducks = ducks;
}
public static Pool GetPool(List<Duck> ducks)
{
return new Pool(ducks);
}
public bool CanAllDucksSwim()
{
foreach (var duck in _ducks)
{
duck.Swim();
}
return true;
}
public bool CanAllDucksQuack()
{
foreach (var duck in _ducks)
{
duck.Quack();
}
return true;
}
}
public class Pool
{
private readonly IList<Duck> _ducks;
Pool(IList<Duck> ducks)
{
_ducks = ducks;
}
public static Pool GetPool(List<Duck> ducks)
{
return new Pool(ducks);
}
public bool CanAllDucksSwim()
{
foreach (var duck in _ducks)
{
duck.Swim();
}
return true;
}
public bool CanAllDucksQuack()
{
foreach (var duck in _ducks)
{
duck.Quack();
}
return true;
}
}
  • Compile the code and make sure that it builds successfully.
Category: .Net, Agile/Scrum, General | Tags: , , ,  | Leave a Comment