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...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Common StateHow do you represent state, different values for which will exist in all instances of a class?In the dawn of computing time, state was all there was. What is a box of punched cards but a bunchof state made manifest? Unit record equipment existed to re-order and transform the state, but allthe transformations were hard-coded (like with wires and pulleys and gears) into the machines.State was king.The first thing electronic computing did was make state virtual. No longer did it only exist inphysical form, that physical form was turned into electrons so it could be more easily and quicklymanipulated. The manipulations were still physically manifest in the form of patch cords, but theywere getting easier to change.The stored program computer changed all this. Now the manipulations and the state were on par.They were both virtual parts of the same machine, stored as charges that could easily be changed.Because of the extreme resource limitations of those early machines, the unification of program andstate became complete. You could encode a program in fewer bytes if you were willing to treat itlike data sometimes, changing the program as circumstances changed. Of course, you could neverhope to just read program source and understand what was happening, you had to watch theprogram in action under lots of different conditions before you understood it.Once we had enough memory that we no longer needed to commit atrocities in the name of spaceefficiency, state still bit us on the backside. Huge programs were written where many manyfunctions used many many different bits of state. No part of the state could be changed withoutchanging many parts of the program.The enormous cost of such programs led to a backlash. Programs as state was bad. State must bebad, too. This led to the development of functional programming, where there is no state, onlyprograms.In spite of their conceptual and mathematical elegance, functional programming languages nevercaught on for commercial software. The problem is that we think, we model in terms of state. Stateis a pretty darn good way to think about the world.Objects represent a middle ground. State is good, but only when properly managed. It ismanageable if it is chopped into little pieces, some alike, some different, and the related programsare chopped into little pieces, some alike, some different. That way, changing part of therepresentation of the state of a program need lead to only a few, localized changes in the program.Declare an instance variable in the class.Instance variables have a very important communicative role to play. They say, once and for all andout in the open, “here’s what I’m modeling with this object”. A set of objects reveals much thatwas in the mind of the original programmer, just by what the instance variables are and what theyare named.Name the variable using Role Suggesting Instance Variable Name. Initialize the instance variableeither with Lazy Initialization, Explicit Initialization, or a Creation Parameter Method. You need tochoose whether to use the variable with Direct Variable Access or Indirect Variable Access.<strong>Coding</strong> <strong>Patterns</strong> page 61 of 147 9/30/2006

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

Saved successfully!

Ooh no, something went wrong!