ctodx

This Blog

News

Favorite Posts

Archives

DevExpress Newsletter 32: Message from the CTO

This time, I start a two-part message. The first part is about writing small single-task methods:

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.

Why do this?

Firstly: it's really easy to write unit tests for simple methods. The more testing you have the more confident you'll be that your application is good and will work both before and after maintenance.

Secondly: it's easier to read a small self-contained method and understand what it does. It's also easier to verify the code in your head, to deskcheck it if you like, increasing your confidence in the validity of the code.

Thirdly: in writing small methods, it's easier to give them understandable names. Once you have those, you make the code easier to read and avoid the need for comments -- and we all know that comments get stale and therefore meaningless.

Fourthly: in writing these small methods, we discover what's known as emergent design. The smaller the methods, the more likely we're going to spot opportunities for creating new classes that have distinct behavior and state. The design of the class model will emerge from our incremental coding.

That last point is extremely important for writing code in a TDD or BDD manner: let the design emerge from our exploratory coding. It's also very important if you're given a hunk of legacy code to maintain. Refactoring it to the Composed Method pattern and using emergent design lets you improve that legacy code and make maintenance easier.

All in all, I'd recommend you look at the Composed Method pattern and start writing small methods.

(You can see the video here.)

The other thing I didn’t mention is that, in .NET, small methods are more likely to be inlined by the JITter at run-time, and in some other languages you can provide hints to the compiler that a method can be inlined if necessary. So the excuse that “calling lots of small methods increases run time” is not necessarily true.

Which leads to another point I’ve made before: we should be writing code in such a way that other people can read and understand it, not for the compiler. After all, the compiler will correctly compile all kinds of badly-written code without complaint (I’m reminded of one app I had to maintain in my early days as a programmer: the original developer had used flower names for all his variables), but it’s the human programmer that has to read, understand, and debug it.

Part two will be available in a fortnight’s time in the next newsletter. SLAP!

Published Aug 18 2010, 02:15 PM by
Filed under:
Bookmark and Share

Comments

Michael Thuma

Hi ok!

Agree, but then you should and I see this if it is not already here the code behind the methods that are used by method to implement. This opens potentials for refactorings ... one sees the evil that will come and not when the unit test is run.

The other way around is less simple and would only working if one strict follows that rule to have a certain responsibility in the context of a layer and the topmost layer minus-n defines the border of the (framework).

As long as the Method invoked does what one can read from it's signature ... then this is not required for this.

Mike

August 19, 2010 3:37 AM

daniel weisel

I fully adopted this programming design after I noticed that long methods are very hard to maintain, and also that comments just clutter up the code (except for critical or complicated methods - I don't bother writing comments thanks to this programming design. The method name tells me the whole story).

What's also great about this design is when you have trouble in the production product. When an error occurs, I first look at the log files; and since the trace stack is all about writing the method signatures - smaller methods means more methods, more methods means more method signatures, which leads to more chances you will be pointed to the exact location in code where the error occurred (as supposed to tracing long and few methods, which you will need to work much harder in finding exactly where in the method the error occurred).

August 19, 2010 7:50 AM

About Julian Bucknall (DevExpress)

Julian is the Chief Technology Officer at Developer Express. You can reach him directly at julianb@devexpress.com. You can also follow him on Twitter with the ID JMBucknall.
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2017 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners