Refactoring: Extract Mixin

I think I might have a previously uncatalogued refactoring here. This is an alpha version. If at least a few people find it useful, I'll do a proper writeup. Here goes:

You have two classes or mixins with similar features.

Create a mixin module, and move the common features to the mixin.

This refactoring is applicable with languages that support mixins, like Ruby.

Motivation

The primary purpose of Extract Mixin is to eliminate code duplication. In this respect, this refactoring is very similar to Extract Superclass. There are some noteworthy differences:
  • Mixins are not a part of the inheritance hierarchy. Thus, it is possible to mix any number of mixins into a class, or into other mixins. Consequently, mixins are more flexible than class hierarchies.
  • Mixins can create instance variables, but this introduces the risk of naming conflicts. Therefore, this refactoring is safest with methods that get all their variables as parameters to the method call.
Extract Mixin can also be used to extract, modularize and encapsulate cross-cutting concerns, for example logging and authentication, in a manner similar to applying advice in Aspect-Oriented Programming (AOP).

Mechanics

  1. Run the test suite to ensure that everything works as it should.
  2. Create a new file containing an empty mixin module.
  3. Include the mixin in the original class (or original mixin).
  4. Run the tests
  5. Move methods, one by one, to the mixin module. Run the tests after each move.
  6. Examine the methods left in the class(es). If there are common parts, use Extract Method to extract those parts into separate methods, then move the methods to the mixin. Run the test suite to verify that everything works.

Example

The following two classes both have a walk() method, but they are in different inheritance hierarchies:


class Human << Mammal
def walk()
...
end
end

class Penguin << Bird
def walk()
...
end
end


By factoring out the walk() method into a mixin, we can eliminate the code duplication:


module Biped
def walk()
...
end
end

class Human << Mammal
include Biped
end

class Penguin << Bird
include Biped
end

Comments

gnupate said…
Nice post, Several of us are going to try this refactoring on a pair or libraries we work on (rwb and r43) to see where it goes. Keep up the good work.
February 15, 2006 8:26 PM
Anonymous said…
I am not sure it needs to be more "proper" than it is, but if you are counting the number of people that find it useful then here is +1.
February 16, 2006 8:22 AM
Kallokain said…
I am glad you liked the post. (And by "glad" I mean jumping up and down and screaming "Yes!" loud enough to frighten the fish in our aquarium.)

I'll do a writeup of the corollary to Extract Mixin, i.e. Replace Mixin With Class, in a few days. I should have done it earlier, but I developed a sudden fanatic interest in process simulation, and haven't been able to think about anything else for a couple of weeks.
February 16, 2006 9:00 AM
Anonymous said…
Sounds great. Btw, is it just me or is there no syndaction feed for your blog? I know that Blogger does not syndicate by default, there is an option somewhere to activate it.
February 20, 2006 11:40 AM
Kallokain said…
The feed is at http://kallokain.blogspot.com/atom.xml. I had turned it
on, but forgot to put a link to it in the page template.

Thanks for pointing it out.
February 20, 2006 7:40 PM
Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che...
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so...
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...
Read more