Fowler's second refactoring pattern is remarkably simple, but it is a classic example of a refactoring that breaks tests for me. It's not generally a big problem but sometimes it makes me wonder if I'm doing something wrong.

The concept is simple, and Fowler puts it well in the summary. But there are two issues that are introduced with what appears to be a simple refactoring pattern. The first and most obvious issue is that this refactoring breaks my tests (see inline_method_refactored.t in the example code for the fixed test). This isn't a big deal exactly, although with larger refactorings of this type it takes some effort to rewrite the tests. The upshot is that, ideally, you really need to rewrite your tests before you perform the refactoring so that you aren't testing the methods that are going away. At the same time, you need to make sure that anything you may have overridden for the sake of isolating tests to specific methods.

The second issue is more of a philosophical question about when and how to refactor. For example, while the get_rating method is small, it is useful to have it extracted because it includes some specific logic. Were I to need this in more than one place, I wouldn't have to worry about whether I repeated the code correctly in more than one place. Even in the case where I am only going to call this method once, it is useful to have it extracted.

I might actually consider refactoring this differently given the right context. From a business logic perspective, it appears that $self->{_number_of_late_deliveries} has some business significance, so I might simply change change the name of the original more_than_five_late_deliveries method to too_many_late_deliveries. Alternately, I might refactor it as Fowler does, but extract the value of the number 5 to a config-ish method called something like late_delivery_threshold.

All of this is simply to point out that refactoring isn't generally as simple as having a technical understanding of a programming language and having a developers understanding of how to make code more maintainable. In a lot of cases, having an understanding of the business domain can be helpful in organizing code effectively.