Bert wrote:

> Conventional wisdom says in that case one should refactor the method because it got too complex, which I agree to if there is a part that makes sense as its own method. However, I personally don't like one-off private methods just for the sake of simplifying one method. These typically need many arguments, have perhaps multiple return values, so the resulting complexity is not worth doing it.  Or am I missing something?

My gauge whether to factor out a one-off is whether I feel inclined to
put a comment above that section of code.  If I do, I figure I may as
well let a message selector BE the comment.

As far as Kent's book, the main highlight benefits of employing
"Composed Method" are:

  - The opportunity to communicate through intention-revealing message
names (<-- my reason).
  - They ease maintenance by isolating assumptions (whether tuning
performance, fixing bugs or enhancing).
  - They make inheritance work smoothly if you decide to specialize
the behavior.

An admitted downside in the book is performance, since more message
sends will be slower.  Another, from my experience, is that in a
system with already a lot of methods, you end up with even more
methods.  This last one has led me to ease-off Composed Method just a
bit over the years.