It is interesting how refactoring is one of the core practices that Kent Beck and Ward Cunningham used on the famous C3 project and that then became part of the arsenal of the extreme programming’s practices.

Due to the iterative nature of extreme programming, a big up front design is unfeasible. Refactoring, unit testing and good object oriented practices allow to have a code that is easy, cheap and safe to change.

An another important point discussed in this chapter is when to refactor. The answer suggested is very similar to what I practice daily:

• Refactor when it helps to introduce a new feature
• Refactor when fixing a bug
• Refactor for better understanding

The most valuable tip is the rule of 3:

The first time, you just do something. The second time, you do something similar you wince at the duplication but you do it anyway. The third time, you refactor.

One last point touched in the chapter was the impact of refactoring on software performance. There are several refactorings (e.g. Remove Temp with Query) that hinder performance. Martin Fowler states that ad hoc and localized performance improvement are expensive and sometimes counterproductive. We should always remember to make the software right and easy to change so that we can improve performance later where the bottlenecks lie. I think this seek for performance everywhere is a cognitive bias that we inherited from the time when developers had to deal with few Ks of memory and expensive processor time.

So far Refactoring Ruby Edition has been enjoyable and I’m looking forward to learn how to refactor in a more disciplined and cautious way.

Discussing the talk one question came out, “When do we introduce value objects, right from the beginning or when certain conditions arise?”

The agreed answer was to introduce them later by refactoring although I now feel that we should introduce them earlier for the following reasons:

• They become useful very quickly
• They help express intent and help understand the domain
• Having few examples of Value Objects in the code base helps new developers pick up good habits because they tend to copy from existing code at the beginning

An interesting side effect of value objects… they make programmers happier! I saw smiles appear on the face of one pair of developers after they figure how value objects helped them avoid some dodgy code duplicated code in the view.

Another side effect of value objects is that they help you avoid null references by facilitating the introduction of Null Objects.

The only things that stops me to use value objects more is the friction that some tools like ORM cause. For example in order to have value objects field properly mapped using Hibernate it is necessary to implement a Custom User Type which can be an onerous an error prone operation.
There is also a lack of refactoring tools that helps you encapsulating one or more fields in a composite object.

The InvestmentFund class looks a bit like the following but 10 times larger:

I am trying to push the use of more granular and less primitive objects in our domain and I am promoting a refactoring of our core domain objects by following three ways suggested in the book Growing Object Oriented Software Guided by Tests:

• Breaking out consists in splitting the responsibilities of large objects in several smaller ones.
• Budding off is used to mark domain concepts in code by creating objects that wrap fields or not fields at all.
• Bundling up consists in assembling in one object a group of values that are generally used together.

A first refactoring bundled up together some of the values of InvestmentFund like the fees information. The result was a type Fee:

which transformed our InvestmentFund class in:

A second refactoring that I would like to pursue is a way to differentiate decimals that represent money and decimals that represent percentages. Budding off those type make sense but I am not sure of the best to model rates.
Do I need a general Percentage type, a more specific InterestRate type or a type for each one of my rate types like “commission”?
The latter looks a bit like what my collegue Mark Needham describes as a Micro-Type.

I will probably start with the simplest solution (a Percentage type) and see how it goes.

Feedback is much appreciated.