13.07.2015 Views

Smalltalk Best Practice Patterns Volume 1: Coding - Free

Smalltalk Best Practice Patterns Volume 1: Coding - Free

Smalltalk Best Practice Patterns Volume 1: Coding - Free

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Composed MethodYou are implementing a method named with an Intention Revealing Selector.How should you divide a program into methods?Programs need to do more than just instruct a computer, they need to communicate to people aswell. How your program is broken into methods, and how big those methods are, is one of the mostimportant decisions you will make as you refine your code so that it communicates as clearly aspossible. The decision is complicated by the many factors affecting it, and the history ofprogramming practice that has traditionally optimized machine resources at the cost of people'stime.Messages take time. The more, smaller methods you create, the more messages you will execute.If all you were worried about was how fast your program would run, you would arrange all of yourcode in a single method. This radical approach to performance tuning invokes enormous humancosts, and ignores the realities of performance tuning well-structured code, which often results inseveral order-of-magnitude improvements.Simple minded performance tuning is not the only factor suggesting that large methods are best.Following the flow of control in programs with many small methods can be difficult. Novice<strong>Smalltalk</strong> programmers often complain that they can't figure out where any "real" work is gettingdone. As you gain experience, you will need to understand the flow of control through severalobjects less often. Well chosen message names let you correctly assume the meaning of invokedcode.The opportunity through intention revealing message names is the most compelling reason to keepmethods small. People can read your programs much more quickly and accurately if they canunderstand them in detail, then chunk those details into higher level structures. Dividing a programinto methods gives you an opportunity to guide that chunk. It is a way for you to subtlycommunicate the structure of your system.Small methods ease maintenance. They let you isolate assumptions. Code that has been writtenwith the right small methods requires the change of only a few methods to correct or enhance itsoperation. This is true whether you are fixing bugs, adding features, or tuning performance.Small methods also make inheritance work smoothly. If you decide to specialize the behavior of aclass written with large methods, you will often find yourself copying the code from the superclassinto the subclass and changing a few lines. You have introduced a multiple update problembetween the superclass method and the subclass method. With small methods, overriding behavioris always a case of overriding a single method.Divide your program into methods that perform one identifiable task. Keep all of theoperations in a method at the same level of abstraction. This will naturally result inprograms with many small methods, each a few lines long.You can use Composed Method top-down. While you are writing a method, you can (withouthaving an implementation yet), invoke several smaller methods. Composed Method becomes athought tool for breaking your development into pieces. Here is an example of a top-downComposed Method:<strong>Coding</strong> <strong>Patterns</strong> page 24 of 147 9/30/2006

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!