The Composed Method pattern

[jazper]

I've been a big fan of this and now I know the actual name for this style of coding.  Anyone else find themselves doing this?  I use to be a bit gun shy on creating so many methods but I truely find code a lot easier to read when the methods are broken down into simpler tasks and the names given to the methods are much more meaningful.

Composed Method pattern:

The Composed Method pattern

One of the things I've adopted over the years in my own programming is the use of small methods -- that is, small as in few lines of code. It's made much easier by the use of a good Extract Method refactoring tool. In my case, that's CodeRush, and it's become second nature to apply Extract Method as I'm writing the code since there no cognitive friction in using it.

I was delighted to learn recently that this practice is known as the Composed Method pattern. It was first devised and promoted by Kent Beck in Smalltalk. In essence, there are three rules to the pattern:

  1. Divide your programs into methods that only perform one identifiable task.
  2. Keep all of the operations in a method at the same level of abstraction.
  3. This will result in programs with many small methods, each a few lines long.

http://community.devexpress.com/blogs/ctodx/archive/2010/08/18/devexpress-newsletter-32-message-from-the-cto.aspx

http://tv.devexpress.com/#ComposedMethodPattern

[phitsc]

Hmm, well, seems like you can make a pattern out of anything .... isn't that just the normal way of doing it??

And how is No. 3 (This will result in ...) a rule?

[mouser]

I'd be interested in hearing more about bullet point #2 -- which sounds good but is not very clear.

I do think it helps especially new coders to get into the habit of isolating code into small functions.  The obvious warning flag that should tell a new coder to create a function is when they find themselves repeating code.

But i also try to tell new coders to always be on the lookout for when they are writing code that they aren't completely sure about -- or code which they may want to optimize later.  The best thing to do in such cases is isolate the code into a function -- it will make it much easier to keep organized in your head when it comes time to revisit the code and improve it.

[kyrathaba]

I find that in actual practice it's more convenient to limit methods to what can fit on my monitor without scrolling.  In other words, there's nothing wrong with a 20-line method, even though I could break it into two or three even smaller methods.  As long as you get the size of the method down to a reasonably small chunk of code that you can get your head around.

[f0dder]

I find that in actual practice it's more convenient to limit methods to what can fit on my monitor without scrolling.  In other words, there's nothing wrong with a 20-line method, even though I could break it into two or three even smaller methods.  As long as you get the size of the method down to a reasonably small chunk of code that you can get your head around.

Really depends on what you're doing, IMHO. The advantage of splitting stuff into small functions, sometimes even as small as 1-3 lines, is that your source code reads out pretty well - eliminating the need for comments.

The practice can also be taken too far, though, resulting in hard-to-navigate almost-spaghetti code.