Composed Method

This is a pattern from SmalltalkBestPracticePatterns by KentBeck:

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

When you use ExtractMethod a bunch of times on a method the original method becomes a ComposedMethod.

ComposedMethod is NOT a synonym for ExtractMethod. The pattern is "Divide your program into methods that perform one identifiable task. Keep all of the operations in a method at the same level of abstraction. This will naturally result in programs with many small methods, each a few lines long."

So the key difference is keeping all the operations in a method at the same level of abstraction? I can see where that might involve more than just a simple method refactoring. You might even generate whole new classes. see also: MethodObject

ComposedMethod then would be what you have after the code has been refactored mercilously, whether the refactorings are ExtractMethod, ExtractClass, something else or some combination thereof.

See ContractiveDelegation

CategoryRefactoring

EditText of this page (last edited November 25, 2003)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004