Sean Chambers

31 Days of Refactoring eBook

schambers — Tue, 20 Oct 2009 23:27:00 GMT

Back in August I did the 31 Days of Refactoring blog series. Fellow LosTechies as well as other community members urged me to convert the series into an eBook. I had intended to (really!), but Simone Chiaretta beat me to it and took it upon himself to create the series into an eBook perfectly formatted and threw in some nice styling.

On that note, and a HUGE thanks to Simone for doing this task, you can find the link to the eBook below. I'm sure I'll format things or may have missed some spelling errors so if you find anything please let me know. Again, huge thanks to Simone for doing this in his spare time. The community thanks you very much as do I.

Pablo's 31 Days of Refactoring eBook

Jacksonville Code Camp 2009

schambers — Tue, 01 Sep 2009 14:04:10 GMT

This past weekend Jacksonville Code Camp took place at University of North Florida campus in Jacksonville. The event was very well organized and donations also went to Goodson’s Children’s Hospital. There was a silent auction fundraiser after the code camp at Sneakers in Jacksonville where all proceeds went towards the children’s hospital.

I did one presentation on SOLID Principles. As noted here are some relevant urls to information about my talk:

http://github.com/schambers/solid-principles/tree/master

At that repository is the presentation and all of the sample code I used during the presentation for your reference.

There was quite a few other interesting presentations. Jim Remsik from HashRocket did a presentation on Agile Storycarding. One of the attendees took some video of the presentation and posted it on vurl which you can find here.

Kevin Wolf demo’d his ORM Smackdown project that shows the differences between several different ORM frameworks along with some great information around each. Kevin definitely put a lot of effort into this detailing and looking at each ORM framework.

I didn’t have a chance to take an immense amount of photos but I did take about 40 that you can find here: http://www.flickr.com/photos/schambers/sets/72157622065448379/

Everyone had a great time and I am already looking forward to next year.

On a sidenote, next weekend (September 5th) is Tally Code Camp in Tallahassee Florida. Shaping up to be another great event. Try to make it out if you can!

31 Days of Refactoring Series complete!

schambers — Mon, 31 Aug 2009 17:34:03 GMT

Well, we have come to the end of the series. I hope everyone has found some value in the series. Some examples were extremely contrived and maybe not all that useful but hopefully someone can use them at some point.

As an added bonus at the end of the series I have committed all of the sample code used in the last 31 days into github. You can find all of the sample code available for download here: http://github.com/schambers/days-of-refactoring/tree/master

After also speaking with fellow LosTechies, I am now going to work towards turning this series into an eBook available for download after making some tweaks to examples with your input that you made along the way.

For reference here is the original introductory post with a listing of all 31 posts:

http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx

I hope everyone enjoyed! Till next time. :D

Refactoring Day 31 : Replace conditional with Polymorphism

schambers — Fri, 28 Aug 2009 16:38:46 GMT

The last day of refactoring comes from Fowlers refactoring catalog and can be found here.

This shows one of the foundations of Object Oriented Programming which is Polymorphism. The concept here is that in instances where you are doing checks by type, and performing some type of operation, it’s a good idea to encapsulate that algorithm within the class and then use polymorphism to abstract the call to the code.

   1: public abstract class Customer

   2: {

   3: }

4:

   5: public class Employee : Customer

   6: {

   7: }

8:

   9: public class NonEmployee : Customer

  10: {

  11: }

12:

  13: public class OrderProcessor

  14: {

  15:     public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)

  16:     {

  17:         // do some processing of order

  18:         decimal orderTotal = products.Sum(p => p.Price);

19:

  20:         Type customerType = customer.GetType();

  21:         if (customerType == typeof(Employee))

  22:         {

  23:             orderTotal -= orderTotal * 0.15m;

  24:         }

  25:         else if (customerType == typeof(NonEmployee))

  26:         {

  27:             orderTotal -= orderTotal * 0.05m;

  28:         }

29:

  30:         return orderTotal;

  31:     }

  32: }

As you can see here, we’re not leaning on our inheritance hierarchy to put the calculation, or even the data needed to perform the calculation lest we have a SRP violation. So to refactor this we simply take the percentage rate and place that on the actual customer type that each class will then implement. I know this is really remedial but I wanted to cover this as well as I have seen it in code.

   1: public abstract class Customer

   2: {

   3:     public abstract decimal DiscountPercentage { get; }

   4: }

5:

   6: public class Employee : Customer

   7: {

   8:     public override decimal DiscountPercentage

   9:     {

  10:         get { return 0.15m; }

  11:     }

  12: }

13:

  14: public class NonEmployee : Customer

  15: {

  16:     public override decimal DiscountPercentage

  17:     {

  18:         get { return 0.05m; }

  19:     }

  20: }

21:

  22: public class OrderProcessor

  23: {

  24:     public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)

  25:     {

  26:         // do some processing of order

  27:         decimal orderTotal = products.Sum(p => p.Price);

28:

  29:         orderTotal -= orderTotal * customer.DiscountPercentage;

30:

  31:         return orderTotal;

  32:     }

  33: }

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

Refactoring Day 30 : Return ASAP

schambers — Fri, 28 Aug 2009 16:38:40 GMT

This topic actually came up during the Remove Arrowhead Antipattern refactoring. The refactoring introduces this as a side effect to remove the arrowhead. To eliminate the arrowhead you return as soon as possible.

   1: public class Order

   2: {

   3:     public Customer Customer { get; private set; }

4:

   5:     public decimal CalculateOrder(Customer customer, IEnumerable<Product> products, decimal discounts)

   6:     {

   7:         Customer = customer;

   8:         decimal orderTotal = 0m;

9:

  10:         if (products.Count() > 0)

  11:         {

  12:             orderTotal = products.Sum(p => p.Price);

  13:             if (discounts > 0)

  14:             {

  15:                 orderTotal -= discounts;

  16:             }

  17:         }

18:

  19:         return orderTotal;

  20:     }

  21: }

The idea is that as soon as you know what needs to be done and you have all the required information, you should exit the method as soon as possible and not continue along.

   1: public class Order

   2: {

   3:     public Customer Customer { get; private set; }

4:

   5:     public decimal CalculateOrder(Customer customer, IEnumerable<Product> products, decimal discounts)

   6:     {

   7:         if (products.Count() == 0)

   8:             return 0;

9:

  10:         Customer = customer;

  11:         decimal orderTotal = products.Sum(p => p.Price);

12:

  13:         if (discounts == 0)

  14:             return orderTotal;

15:

  16:         orderTotal -= discounts;

17:

  18:         return orderTotal;

  19:     }

  20: }

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

Refactoring Day 29 : Remove Middle Man

schambers — Fri, 28 Aug 2009 16:38:31 GMT

Today’s refactoring comes from Fowler’s refactoring catalog and can be found here.

Sometimes in code you may have a set of “Phantom” or “Ghost” classes. Fowler calls these “Middle Men”. Middle Men classes simply take calls and forward them on to other components without doing any work. This is an unneeded layer and can be removed completely with minimal effort.

   1: public class Consumer

   2: {

   3:     public AccountManager AccountManager { get; set; }

4:

   5:     public Consumer(AccountManager accountManager)

   6:     {

   7:         AccountManager = accountManager;

   8:     }

9:

  10:     public void Get(int id)

  11:     {

  12:         Account account = AccountManager.GetAccount(id);

  13:     }

  14: }

15:

  16: public class AccountManager

  17: {

  18:     public AccountDataProvider DataProvider { get; set; }

19:

  20:     public AccountManager(AccountDataProvider dataProvider)

  21:     {

  22:         DataProvider = dataProvider;

  23:     }

24:

  25:     public Account GetAccount(int id)

  26:     {

  27:         return DataProvider.GetAccount(id);

  28:     }

  29: }

30:

  31: public class AccountDataProvider

  32: {

  33:     public Account GetAccount(int id)

  34:     {

  35:         // get account

  36:     }

  37: }

The end result is straightforward enough. We just remove the middle man object and point the original call to the intended receiver.

   1: public class Consumer

   2: {

   3:     public AccountDataProvider AccountDataProvider { get; set; }

4:

   5:     public Consumer(AccountDataProvider dataProvider)

   6:     {

   7:         AccountDataProvider = dataProvider;

   8:     }

9:

  10:     public void Get(int id)

  11:     {

  12:         Account account = AccountDataProvider.GetAccount(id);

  13:     }

  14: }

15:

  16: public class AccountDataProvider

  17: {

  18:     public Account GetAccount(int id)

  19:     {

  20:         // get account

  21:     }

  22: }

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

Refactoring Day 28 : Rename boolean method

schambers — Fri, 28 Aug 2009 12:12:10 GMT

Today’s refactoring doesn’t necessarily come from Fowlers refactoring catalog. If anyone knows where this “refactoring” actually comes from, please let me know.

Granted, this could be viewed as not being a refactoring as the methods are actually changing, but this is a gray area and open to debate. Methods with a large number of boolean parameters can quickly get out of hand and can produce unexpected behavior. Depending on the number of parameters will determine how many methods need to be broken out. Let’s take a look at where this refactoring starts:

   1: public class BankAccount

   2: {

   3:     public void CreateAccount(Customer customer, bool withChecking, bool withSavings, bool withStocks)

   4:     {

   5:         // do work

   6:     }

   7: }

We can make this work a little better simple by exposing the boolean parameters via well named methods and in turn make the original method private to prevent anyone from calling it going forward. Obviously you could have a large number of permutations here and perhaps it makes more sense to refactor to a Parameter object instead.

   1: public class BankAccount

   2: {

   3:     public void CreateAccountWithChecking(Customer customer)

   4:     {

   5:         CreateAccount(customer, true, false);

   6:     }

7:

   8:     public void CreateAccountWithCheckingAndSavings(Customer customer)

   9:     {

  10:         CreateAccount(customer, true, true);

  11:     }

12:

  13:     private void CreateAccount(Customer customer, bool withChecking, bool withSavings)

  14:     {

  15:         // do work

  16:     }

  17: }

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

Refactoring Day 27 : Remove God Classes

schambers — Thu, 27 Aug 2009 12:17:13 GMT

Often with legacy code bases I will often come across classes that are clear SRP violations. Often these classes will be suffixed with either “Utils” or “Manager”. Sometimes they don’t have this indication and are just classes with multiple grouped pieces of functionality. Another good indicator of a God class is methods grouped together with using statements or comments into seperate roles that this one class is performing.

Over time, these classes become a dumping ground for a method that someone doesn’t have time/want to put in the proper class. The refactoring for situations like these is to break apart the methods into distinct classes that are responsible for specific roles.

   1: public class CustomerService

   2: {

   3:     public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer)

   4:     {

   5:         // do work

   6:     }

7:

   8:     public bool CustomerIsValid(Customer customer, Order order)

   9:     {

  10:         // do work

  11:     }

12:

  13:     public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer)

  14:     {

  15:         // do work

  16:     }

17:

  18:     public void Register(Customer customer)

  19:     {

  20:         // do work

  21:     }

22:

  23:     public void ForgotPassword(Customer customer)

  24:     {

  25:         // do work

  26:     }

  27: }

The refactoring for this is very straight forward. Simply take the related methods and place them in specific classes that match their responsibility. This makes them much finer grained and defined in what they do and make future maintenance much easier. Here is the end result of splitting up the methods above into two distinct classes.

   1: public class CustomerOrderService

   2: {

   3:     public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer)

   4:     {

   5:         // do work

   6:     }

7:

   8:     public bool CustomerIsValid(Customer customer, Order order)

   9:     {

  10:         // do work

  11:     }

12:

  13:     public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer)

  14:     {

  15:         // do work

  16:     }

  17: }

18:

  19: public class CustomerRegistrationService

  20: {

21:

  22:     public void Register(Customer customer)

  23:     {

  24:         // do work

  25:     }

26:

  27:     public void ForgotPassword(Customer customer)

  28:     {

  29:         // do work

  30:     }

  31: }

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

Refactoring Day 26 : Remove Double Negative

schambers — Wed, 26 Aug 2009 12:08:51 GMT

Today’s refactoring comes from Fowler’s refactoring catalog and can be found here.

This refactoring is pretty simple to implement although I find it in many codebases that severely hurts readability and almost always conveys incorrect intent. This type of code does the most damage because of the assumptions made on it. Assumptions lead to incorrect maintenance code written, which in turn leads to bugs. Take the following example:

   1: public class Order

   2: {

   3:     public void Checkout(IEnumerable<Product> products, Customer customer)

   4:     {

   5:         if (!customer.IsNotFlagged)

   6:         {

   7:             // the customer account is flagged

   8:             // log some errors and return

   9:             return;

  10:         }

11:

  12:         // normal order processing

  13:     }

  14: }

15:

  16: public class Customer

  17: {

  18:     public decimal Balance { get; private set; }

19:

  20:     public bool IsNotFlagged

  21:     {

  22:         get { return Balance < 30m; }

  23:     }

  24: }

As you can see the double negative here is difficult to read because we have to figure out what is positive state of the two negatives. The fix is very easy. If we don’t have a positive test, add one that does the double negative assertion for you rather than make sure you get it correct.

   1: public class Order

   2: {

   3:     public void Checkout(IEnumerable<Product> products, Customer customer)

   4:     {

   5:         if (customer.IsFlagged)

   6:         {

   7:             // the customer account is flagged

   8:             // log some errors and return

   9:             return;

  10:         }

11:

  12:         // normal order processing

  13:     }

  14: }

15:

  16: public class Customer

  17: {

  18:     public decimal Balance { get; private set; }

19:

  20:     public bool IsFlagged

  21:     {

  22:         get { return Balance >= 30m; }

  23:     }

  24: }

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

Refactoring Day 25 : Introduce Design By Contract checks

schambers — Tue, 25 Aug 2009 12:02:49 GMT

Design By Contract or DBC defines that methods should have defined input and output verifications. Therefore, you can be sure you are always working with a usable set of data in all methods and everything is behaving as expected. If not, exceptions or errors should be returned and handled from the methods. To read more on DBC read the wikipedia page here.

In our example here, we are working with input parameters that may possibly be null. As a result a NullReferenceException would be thrown from this method because we never verify that we have an instance. During the end of the method, we don’t ensure that we are returning a valid decimal to the consumer of this method and may introduce methods elsewhere.

   1: public class CashRegister

   2: {

   3:     public decimal TotalOrder(IEnumerable<Product> products, Customer customer)

   4:     {

   5:         decimal orderTotal = products.Sum(product => product.Price);

6:

   7:         customer.Balance += orderTotal;

8:

   9:         return orderTotal;

  10:     }

  11: }

The changes we can make here to introduce DBC checks is pretty easy. First we will assert that we don’t have a null customer, check that we have at least one product to total. Before we return the order total we will ensure that we have a valid amount for the order total. If any of these checks fail in this example we should throw targeted exceptions that detail exactly what happened and fail gracefully rather than throw an obscure NullReferenceException.

It seems as if there is some DBC framework methods and exceptions in the Microsoft.Contracts namespace that was introduced with .net framework 3.5. I personally haven’t played with these yet, but they may be worth looking at. This is the only thing I could find on msdn about the namespace.

   1: public class CashRegister

   2: {

   3:     public decimal TotalOrder(IEnumerable<Product> products, Customer customer)

   4:     {

   5:         if (customer == null)

   6:             throw new ArgumentNullException("customer", "Customer cannot be null");

   7:         if (products.Count() == 0)

   8:             throw new ArgumentException("Must have at least one product to total", "products");

9:

  10:         decimal orderTotal = products.Sum(product => product.Price);

11:

  12:         customer.Balance += orderTotal;

13:

  14:         if (orderTotal == 0)

  15:             throw new ArgumentOutOfRangeException("orderTotal", "Order Total should not be zero");

16:

  17:         return orderTotal;

  18:     }

  19: }

It does add more code to the method for validation checks and you can go overboard with DBC, but I think in most scenarios it is a worthwhile endeavor to catch sticky situations. It really stinks to chase after a NullReferenceException without detailed information.

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

Refactoring Day 24 : Remove Arrowhead Antipattern

schambers — Mon, 24 Aug 2009 12:00:39 GMT

Today’s refactoring is based on the c2 wiki entry and can be found here. Los Techies own Chris Missal also did a very informative post on the antipattern that you can find here.

Simply put, the arrowhead antipattern is when you have nested conditionals so deep that they form an arrowhead of code. I see this very often in different code bases and it makes for high cyclomatic complexity in code.

A good example of the arrowhead antipattern can be found in this sample here:

   1: public class Security

   2: {

   3:     public ISecurityChecker SecurityChecker { get; set; }

4:

   5:     public Security(ISecurityChecker securityChecker)

   6:     {

   7:         SecurityChecker = securityChecker;

   8:     }

9:

  10:     public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions)

  11:     {

  12:         bool hasPermission = false;

13:

  14:         if (user != null)

  15:         {

  16:             if (permission != null)

  17:             {

  18:                 if (exemptions.Count() == 0)

  19:                 {

  20:                     if (SecurityChecker.CheckPermission(user, permission) || exemptions.Contains(permission))

  21:                     {

  22:                         hasPermission = true;

  23:                     }

  24:                 }

  25:             }

  26:         }

27:

  28:         return hasPermission;

  29:     }

  30: }

Refactoring away from the arrowhead antipattern is as simple as swapping the conditionals to leave the method as soon as possible. Refactoring in this manner often starts to look like Design By Contract checks to evaluate conditions before performing the work of the method. Here is what this same method might look like after refactoring.

   1: public class Security

   2: {

   3:     public ISecurityChecker SecurityChecker { get; set; }

4:

   5:     public Security(ISecurityChecker securityChecker)

   6:     {

   7:         SecurityChecker = securityChecker;

   8:     }

9:

  10:     public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions)

  11:     {

  12:         if (user == null || permission == null)

  13:             return false;

14:

  15:         if (exemptions.Contains(permission))

  16:             return true;

17:

  18:         return SecurityChecker.CheckPermission(user, permission);

  19:     }

  20: }

As you can see, this method is much more readable and maintainable going forward. It’s not as difficult to see all the different paths you can take through this method.

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

Refactoring Day 23 : Introduce Parameter Object

schambers — Sun, 23 Aug 2009 11:06:49 GMT

This refactoring comes from Fowler’s refactoring catalog and can be found here

Sometimes when working with a method that needs several parameters it becomes difficult to read the method signature because of five or more parameters being passed to the method like so:

   1: public class Registration

   2: {

   3:     public void Create(decimal amount, Student student, IEnumerable<Course> courses,

   4:         decimal credits)

   5:     {

   6:         // do work

   7:     }

   8: }

In this instances it’s useful to create a class who’s only responsibility is to carry parameters into the method. This helps make the code more flexible because to add more parameters, you need only to add another field to the parameter object. Be careful to only use this refactoring when you find that you have a large number of parameters to pass to the method however as it does add several more classes to your codebase and should be kept to a minimum.

   1: public class RegistrationContext

   2: {

   3:     public decimal Amount { get; set; }

   4:     public Student Student { get; set; }

   5:     public IEnumerable<Course> Courses { get; set; }

   6:     public decimal Credits { get; set; }

   7: }

8:

   9: public class Registration

  10: {

  11:     public void Create(RegistrationContext registrationContext)

  12:     {

  13:         // do work

  14:     }

  15: }

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

Refactoring Day 22 : Break Method

schambers — Sat, 22 Aug 2009 20:25:50 GMT

Today’s refactoring didn’t really come from any one source. It just named it although someone else may have something similar that’s named differently. If you know of anyone that has a name for this other than Break Method, please let me know.

This refactoring is kind of a meta-refactoring in the fact that it’s just extract method applied over and over until you decompose one large method into several smaller methods. This example here is a tad contrived because the AcceptPayment method isn’t doing as much as I wanted. Imagine that there is much more supporting code around each action that the one method is doing. That would match a real world scenario if you can picture it that way.

Below we have the AcceptPayment method that can be decomposed multiple times into distinct methods.

   1: public class CashRegister

   2: {

   3:     public CashRegister()

   4:     {

   5:         Tax = 0.06m;

   6:     }

7:

   8:     private decimal Tax { get; set; }

9:

  10:     public void AcceptPayment(Customer customer, IEnumerable<Product> products, decimal payment)

  11:     {

  12:         decimal subTotal = 0m;

  13:         foreach (Product product in products)

  14:         {

  15:             subTotal += product.Price;

  16:         }

17:

  18:         foreach(Product product in products)

  19:         {

  20:             subTotal -= product.AvailableDiscounts;

  21:         }

22:

  23:         decimal grandTotal = subTotal * Tax;

24:

  25:         customer.DeductFromAccountBalance(grandTotal);

  26:     }

  27: }

28:

  29: public class Customer

  30: {

  31:     public void DeductFromAccountBalance(decimal amount)

  32:     {

  33:         // deduct from balance

  34:     }

  35: }

36:

  37: public class Product

  38: {

  39:     public decimal Price { get; set; }

  40:     public decimal AvailableDiscounts { get; set; }

  41: }

As you can see the AcceptPayment method has a couple of things that can be decomposed into targeted methods. So we perform the Extract Method refactoring a number of times until we come up with the result:

   1: public class CashRegister

   2: {

   3:     public CashRegister()

   4:     {

   5:         Tax = 0.06m;

   6:     }

7:

   8:     private decimal Tax { get; set; }

   9:     private IEnumerable<Product> Products { get; set; }

10:

  11:     public void AcceptPayment(Customer customer, IEnumerable<Product> products, decimal payment)

  12:     {

  13:         decimal subTotal = CalculateSubtotal();

14:

  15:         subTotal = SubtractDiscounts(subTotal);

16:

  17:         decimal grandTotal = AddTax(subTotal);

18:

  19:         SubtractFromCustomerBalance(customer, grandTotal);

  20:     }

21:

  22:     private void SubtractFromCustomerBalance(Customer customer, decimal grandTotal)

  23:     {

  24:         customer.DeductFromAccountBalance(grandTotal);

  25:     }

26:

  27:     private decimal AddTax(decimal subTotal)

  28:     {

  29:         return subTotal * Tax;

  30:     }

31:

  32:     private decimal SubtractDiscounts(decimal subTotal)

  33:     {

  34:         foreach(Product product in Products)

  35:         {

  36:             subTotal -= product.AvailableDiscounts;

  37:         }

  38:         return subTotal;

  39:     }

40:

  41:     private decimal CalculateSubtotal()

  42:     {

  43:         decimal subTotal = 0m;

  44:         foreach (Product product in Products)

  45:         {

  46:             subTotal += product.Price;

  47:         }

  48:         return subTotal;

  49:     }

  50: }

51:

  52: public class Customer

  53: {

  54:     public void DeductFromAccountBalance(decimal amount)

  55:     {

  56:         // deduct from balance

  57:     }

  58: }

59:

  60: public class Product

  61: {

  62:     public decimal Price { get; set; }

  63:     public decimal AvailableDiscounts { get; set; }

  64: }

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

Refactoring Day 21 : Collapse Hierarchy

schambers — Fri, 21 Aug 2009 12:23:00 GMT

Todays refactoring comes from Martin Fowlers catalog of patterns. You can find this refactoring in his catalog here

Yesterday we looked at extracting a subclass for moving responsibilities down if they are not needed across the board. A Collapse Hierarchy refactoring would be applied when you realize you no longer need a subclass. When this happens it doesn’t really make sense to keep your subclass around if it’s properties can be merged into the base class and used strictly from there.

   1: public class Website

   2: {

   3:     public string Title { get; set; }

   4:     public string Description { get; set; }

   5:     public IEnumerable<Webpage> Pages { get; set; }

   6: }

7:

   8: public class StudentWebsite : Website

   9: {

  10:     public bool IsActive { get; set; }

  11: }

Here we have a subclass that isn’t doing too much. It just has one property to denote if the site is active or not. At this point maybe we realize that determing if a site is active is something we can use across the board so we can collapse the hierarchy back into only a Website and eliminate the StudentWebsite type.

   1: public class Website

   2: {

   3:     public string Title { get; set; }

   4:     public string Description { get; set; }

   5:     public IEnumerable<Webpage> Pages { get; set; }

   6:     public bool IsActive { get; set; }

   7: }

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

Refactoring Day 20 : Extract Subclass

schambers — Thu, 20 Aug 2009 12:08:00 GMT

Todays refactoring comes from Martin Fowlers catalog of patterns. You can find this refactoring in his catalog here

This refactoring is useful when you have methods on a base class that are not shared amongst all classes and needs to be pushed down into it’s own class. The example I’m using here is pretty straightforward. We start out with a single class called Registration. This class handles all information related to a student registering for a course.

   1: public class Registration

   2: {

   3:     public NonRegistrationAction Action { get; set; }

   4:     public decimal RegistrationTotal { get; set; }

   5:     public string Notes { get; set; }

   6:     public string Description { get; set; }

   7:     public DateTime RegistrationDate { get; set; }

   8: }

There is something that we’ve realized after working with this class. We are using it in two different contexts. The properties NonRegistrationAction and Notes are only ever used when dealing with a NonRegistration which is used to track a portion of the system that is slightly different than a normal registration. Noticing this, we can extract a subclass and move those properties down into the NonRegistration class where they more appropriately fit.

   1: public class Registration

   2: {

   3:     public decimal RegistrationTotal { get; set; }

   4:     public string Description { get; set; }

   5:     public DateTime RegistrationDate { get; set; }

   6: }

7:

   8: public class NonRegistration : Registration

   9: {

  10:     public NonRegistrationAction Action { get; set; }

  11:     public string Notes { get; set; }

  12: }

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