Refactoring Day 2 : Move Method

The refactoring today is pretty straightforward, although often overlooked and ignored as being a worthwhile refactoring. Move method does exactly what it sounds like, move a method to a better location. Let’s look at the following code before our refactoring:

   1: public class BankAccount
   2: {
   3:     public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest)
   4:     {
   5:         AccountAge = accountAge;
   6:         CreditScore = creditScore;
   7:         AccountInterest = accountInterest;
   8:     }
   9:  
  10:     public int AccountAge { get; private set; }
  11:     public int CreditScore { get; private set; }
  12:     public AccountInterest AccountInterest { get; private set; }
  13:  
  14:     public double CalculateInterestRate()
  15:     {
  16:         if (CreditScore > 800)
  17:             return 0.02;
  18:  
  19:         if (AccountAge > 10)
  20:             return 0.03;
  21:  
  22:         return 0.05;
  23:     }
  24: }
  25:  
  26: public class AccountInterest
  27: {
  28:     public BankAccount Account { get; private set; }
  29:  
  30:     public AccountInterest(BankAccount account)
  31:     {
  32:         Account = account;
  33:     }
  34:  
  35:     public double InterestRate
  36:     {
  37:         get { return Account.CalculateInterestRate(); }
  38:     }
  39:  
  40:     public bool IntroductoryRate
  41:     {
  42:         get { return Account.CalculateInterestRate() < 0.05; }
  43:     }
  44: }



The point of interest here is the BankAccount.CalculateInterest method. A hint that you need the Move Method refactoring is when another class is using a method more often then the class in which it lives. If this is the case it makes sense to move the method to the class where it is primarily used. This doesn’t work in every instance because of dependencies, but it is overlooked often as a worthwhile change.

In the end you would end up with something like this:

   1: public class BankAccount
   2: {
   3:     public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest)
   4:     {
   5:         AccountAge = accountAge;
   6:         CreditScore = creditScore;
   7:         AccountInterest = accountInterest;
   8:     }
   9:  
  10:     public int AccountAge { get; private set; }
  11:     public int CreditScore { get; private set; }
  12:     public AccountInterest AccountInterest { get; private set; }
  13: }
  14:  
  15: public class AccountInterest
  16: {
  17:     public BankAccount Account { get; private set; }
  18:  
  19:     public AccountInterest(BankAccount account)
  20:     {
  21:         Account = account;
  22:     }
  23:  
  24:     public double InterestRate
  25:     {
  26:         get { return CalculateInterestRate(); }
  27:     }
  28:  
  29:     public bool IntroductoryRate
  30:     {
  31:         get { return CalculateInterestRate() < 0.05; }
  32:     }
  33:  
  34:     public double CalculateInterestRate()
  35:     {
  36:         if (Account.CreditScore > 800)
  37:             return 0.02;
  38:  
  39:         if (Account.AccountAge > 10)
  40:             return 0.03;
  41:  
  42:         return 0.05;
  43:     }
  44: }

 

Simple enough!

This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Sean Chambers

I am a Senior software developer from Palm Coast, Florida. An advocate of Domain Driven Design, Behavior Driven Development, creator of FluentMigrator and community activist. I am married to my beautiful wife Erin and am the proud father of two wonderful children. I currently reside at ACI, a local insurance industry/mortgage software company that excels in creating solutions using Agile methodologies.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://neilmosafi.blogspot.com Neil Mosafi

    I’m not sure about the purpose of the classes here, and whatsmore you seem to have a circular dependency in your constructors – you can’t construct a BankAccount without an AccountInterest and you can’t construct an AccountInterest without a BankAccount!

  • http://www.lostechies.com/members/schambers/default.aspx schambers

    Obviously these are brief contrived examples so there is no usage surrounding them. This is for brevity.

    You are correct about the circular dependencies though. I didn’t catch that while making the example. Let’s just pretend that there is no circular dependency there. k?

  • Frank

    In my opinion this is a bad refactoring example, since the calculate interest method is best suited to the account class, since that class owns all the data necessary for making the decision.

  • Arnis L.

    @Frank it’s not. Bad code gets refactored – this one suits perfectly.

  • nfma

    @Arnis, I agree with Frank. If I looked at the code from the solution I tended to refactor it to match the original code.

  • Cameron Scott

    Since it can be difficult to find human opponents for a face-to-face game and I don’t like playing against the computer, I will have to try out the internet chess site. Thanks for the info.

    http://healthconditions.edublogs.org/