Smalltalk Best Practice Patterns Volume 1: Coding - Free

More documents

Recommendations

Info

BehaviorObjects model the world through behavior and state. Behavior is the dynamic, active,computational part of the model. State is what is left after behavior is done, how the model isrepresented before, after, and during a computation.Of the two, behavior is the more important to get right. The primacy of behavior is one of the oddtruths of objects, odd because it flies in the face of so much accumulated experience. Back in thebad old days you wanted to get the representation right as quickly as possible, because everychange to the representation bred changes in many different computations.Objects (done right) change all that. No longer is your system a slave of its representation. Becauseobjects can hide their representation behind a wall of messages, you are free to changerepresentation and only affect one object.Behavior in systems of objects is specified in two ways, with messages and methods. I saw a greatcomment at OOPSLA (the Object Oriented Programming Languages, Systems and Applicationsconference). It said, “This seems an awful fuss for a fancy procedure call.” Well, separatingcomputation into messages and methods and binding the message to the method at runtime basedon the class of the receiver may seem like a small change from an ordinary procedure call, but it isa small change that makes a big difference.This section tells you how to specify behavior so that your intent is clearly communicated to yourreader. Many constraints affect your choices when specifying behavior. The more centralized theflow of control, the easier it is to follow in the sense that you don’t have to go bouncing around allover the place to understand how work is accomplished. However, centralizing control killsflexibility. You want to have lots of objects involved, so you have many opportunities to replaceobjects to change the system, and so you can completely factor code.Coding Patterns page 22 of 147 9/30/2006
MethodsMethods are important to the system because they are how work gets done in Smalltalk. Just asimportant, methods are how you communicate to readers how you intended for work to get done.You must write your methods with both of these audiences in mind. Methods must do the workthey are supposed to do, but they must also communicate the intent of the work to be done.Methods decompose the function of your program into easily digestible chunks. Carefully breakinga computation into methods and carefully choosing their names communicates more about yourintentions to a reader than any other programming decision besides class naming.Methods are the granularity of overriding. A well factored superclass can always be specialized byoverriding a single method, without having to copy part of the superclass code into the subclass.Methods don’t come for free. Managing all those bits and pieces of code- writing them in the firstplace; naming them; remembering, rediscovering, and communicating how they all fit together- alltake time. If there is no benefit to be gained, bigger methods would be better than small because ofthe reduced management overhead.Methods cost in performance as well. Each method invocation takes precious computer cycles.The trick to getting good performance is using methods as a lever to make your performancemeasurement and tuning more effective. In my experience, better factored code, with lots of smallmethods, both allows more accurate and concise performance measurement (because there aren’tlittle snippets of code duplicated all over) and provides leverage for tuning (through techniques likeCaching Instance Variable).Overall, the goal of breaking your program into methods is to communicate your intent clearly withyour reader, provide for future flexibility, and set yourself up for effective performance tuningwhere necessary.Coding Patterns page 23 of 147 9/30/2006
Page 1 and 2: Smalltalk Best Practice PatternsVol
Page 3 and 4: STATE..............................
Page 5 and 6: PrefaceThis preface will explain wh
Page 7: AcknowledgmentsI would like to than
Page 10 and 11: Many of the patterns tell you what
Page 12 and 13: day to day in development and docum
Page 14 and 15: What’s Missing?There are a few co
Page 16 and 17: AdoptionHow can you learn and use t
Page 18 and 19: Why Patterns WorkHere is the Big As
Page 20 and 21: Role of PatternsReadingThese patter
Page 24 and 25: Composed MethodYou are implementing
Page 26 and 27: Complete Creation MethodA Composed
Page 28 and 29: ConversionHow do you convert inform
Page 30 and 31: Converter Creation MethodYou need t
Page 32 and 33: Query MethodA Composed Method has h
Page 34 and 35: Execute Around MethodHow do you rep
Page 36 and 37: MessagesMessages are the heartbeat
Page 38 and 39: Choosing MessageYou are using a Mes
Page 40 and 41: Decomposing MessageYou are using a
Page 42 and 43: Intention Revealing SelectorYou may
Page 44 and 45: Integer>>addFloat: aFloat^self asFl
Page 46 and 47: Class: SuperFindingClientsuperclass
Page 48 and 49: Extending SuperYou are using Super.
Page 50 and 51: DelegationA Composed Method needs w
Page 52 and 53: Self DelegationYou are using Delega
Page 54 and 55: Pluggable BehaviorHow can you param
Page 56 and 57: Pluggable BlockYou need complex Plu
Page 58 and 59: marriedMenAndUnmarriedWomen^self ma
Page 60 and 61: Instance VariablesI wrote the secti
Page 62 and 63: Variable StateHow do you represent
Page 64 and 65: Timer>>defaultMillisecondPeriod^100
Page 66 and 67: Default Value MethodYou have a comp
Page 68 and 69: Direct Variable AccessYou need to a
Page 70 and 71: Getting MethodYou are using Lazy In
Page 72 and 73:
Collection Accessor MethodYou are u
Page 74 and 75:
Enumeration MethodYou are using Ind
Page 76 and 77:
Role Suggesting Instance Variable N
Page 78 and 79:
Temporary VariableA Composed Method
Page 80 and 81:
Caching Temporary VariableA Perform
Page 82 and 83:
Reusing Temporary VariableTemporary
Page 84 and 85:
CollectionsThe collection hierarchy
Page 86 and 87:
CollectionHow do you represent a on
Page 88 and 89:
RunArrayYou are using an OrderedCol
Page 90 and 91:
| s |s := Set new.Like an OrderedCo
Page 92 and 93:
You may need Double Dispatch for co
Page 94 and 95:
DictionaryYou need a Collection tha
Page 96 and 97:
SortedCollectionYou have a Collecti
Page 98 and 99:
ByteArrayYou need to represent an A
Page 100 and 101:
(1 to: anArray size) collect:[:each
Page 102 and 103:
IsEmptyHow do you test if a collect
Page 104 and 105:
ConcatentationHow do you put two co
Page 106 and 107:
DoHow do you execute code for each
Page 108 and 109:
Select/RejectHow do you execute cod
Page 110 and 111:
Inject:into:You need an Enumeration
Page 112 and 113:
Duplicate Removing SetYou have a Co
Page 114 and 115:
StackHow do you implement a stack?O
Page 116 and 117:
implementation of queues in Pascal
Page 118 and 119:
Lookup CacheHow do you optimize com
Page 120 and 121:
Parsing StreamHow do you write a si
Page 122 and 123:
ClassesThere is probably no coding
Page 124 and 125:
Qualified Subclass NameYou have cre
Page 126 and 127:
FormattingNo other topic generates
Page 128 and 129:
Type Suggesting Parameter NameYou a
Page 130 and 131:
Rectangular BlockYou are writing an
Page 132 and 133:
Conditional ExpressionHow do you fo
Page 134 and 135:
Simple Enumeration ParameterWhat sh
Page 136 and 137:
self listPane parentcolor: Color bl
Page 138 and 139:
Point>>printOn: aStreamaStreamprint
Page 140 and 141:
Development ExampleIn this chapter,
Page 142 and 143:
Money>>setAmount: aNumber currency:
Page 144 and 145:
MoneySum>>printOn: aStreammonies do
Page 146:
| m1 m2 |m1 := Moneyamount: 5curren
show all

Smalltalk Best Practice Patterns Volume 1: Coding - Free

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

Delete template?

Save as template?