Today’s refactoring doesn’t come from any place specifically, just something I’ve picked up over time that I find myself using often. Any variations/comments would be appreciated to this approach. I think there’s some other good refactorings around these type of … Continue reading →

Today’s refactoring is from Martin Fowler’s refactoring catalog. You can find the original description here This refactoring is used quite often when you have a number of methods that you want to “pull up” into a base class to allow … Continue reading →

Sometimes when doing a number of different checks within a conditional the intent of what you are testing for gets lost in the conditional. In these instances I like to extract the conditional into an easy to read property, or … Continue reading →

A day late on this one. Sorry about that! This is probably one of the most used refactoring in the forms of methods that are used in more than one place. Duplication will quickly sneak up on you if you’re … Continue reading →

When breaking apart responsibilities on a class this is enforcing Single Responsiblity Principle from SOLID. It’s an easy approach to apply this refactoring although it’s often disputed as what consitutes a “responsibility”. While I won’t be answering that here, I … Continue reading →

Today’s refactoring comes from Martin Fowlers list of refactorings. You can find his original article here with a brief description. This is a more infrequent refactoring that I see myself using but it comes in handy at times. When trying … Continue reading →

Today’s refactoring is useful if you are trying to introduce unit tests into your code base as testing “seams” are needed to properly mock/isolate areas you don’t wish to test. In this example we have client code that is using … Continue reading →

Todays refactoring doesn’t come from any one source, rather I’ve used different versions over the years and I’m sure other have different variations of the same aim. This refactoring is used when you have a larger switch statement that continually … Continue reading →

Today we look at the Extract Method refactoring. This is an extremely easy refactoring with several benefits. First, it helps to make code more readable by placing logic behind descriptive method names. This reduces the amount of investigation the next … Continue reading →

Today we look at an often overlooked refactoring. Extract Interface. When you notice more than one class using a similar subset of methods on a class, it is useful to break the dependency and introduce an interface that the consumers … Continue reading →