Extract Responsibility Refactoring.

In Martin Fowler’s “Refactoring” he introduces the “Extract Class” refactoring. I love this refactoring pattern and I use it all the time.

This refactoring is (unless im sorely mistaken) the most important one for the SRP.

Because of this intimacy with the SRP, I think there is an umbrella refactoring, called “Extract Responsibility” with two concrete methods for achieving it:

• Extract Component (formerly Extract Class)
• Extract Process (sometimes “Form Template Method”).

Extract Responsibility

You have one class responsible for the work that should be done by two.

Decide if the extra responsibility is encapsulated as a Component (Has-A) or a Process (IoC)

Extract Component

You have one class with an additional responsibility that exhibits compositional behaviour

Create a new class and move the relevant fields and methods from the old class into the new class (lifted directly from Extract Class)

The new class is a component if all it takes to make the refactoring, is to move methods. In my experience you are ‘Extracting A Component’ if the original classes’ data easily fits into a “Has-A” relationship.

Extract Process

You have two methods in subclasses that perform similar steps in the same order, yet the steps are different. (lifted directly from “Form Template Method”)

Create a new class, add process hooks in the new class and use those to call on the original classes actions.

OK so here is the crux of the matter. There are classes that still have too much responsibility, but it’s not in a ‘Has-A’ relationship. These classes have a ‘process’. These classes often present themselves in sets. Usually you will find two classes doing the exact same thing with moderately different behaviour.

The most suitable term for this extraction is “Inversion of Control”. Please don’t think I mean DI. DI, especially automated DI, is “Orthogonal Control” in my mind (topic of another post I must write).

The most common way I’ve seen of inverting control for a class or set of classes is the Form Template Method Refactoring. There are probably quite a few other methods for achieving IoC, including utilizing annotations.

The one I prefer is the Fluent Interface, and a beautiful example of IoC in fluent interfaces is Shaun Smith’s Promise Class.

In general I prefer Fluent Interfaces over Template Methods because they turn an ‘Is-a’ into a ‘Has-a’, providing far less coupling, and allowing for more than one ‘Process’ to be utilized by any given class.

This actually makes the new Fluent class a “has-a” relationship, so how does this differ from ‘Extract Component’? - You are not extracting data, you are extracting common behavior.

There is one downside to Fluent Interfaces: Language support.

In languages like Actionscript 3, you cannot delegate methods with static typing. This means that the callbacks you give your fluent interface are not compile time checked. In my next ‘Actionscript 4’ article I’ll talk more about static typed delegates and how much I think we need them in the language.

Finally

My apologies that my writing is not succinct. Writing is a craft I need to take more time to master. So please, feedback, opinions and constructive criticism!