OO, patterns, and Smalltalk

Do not comment bad code -- rewrite it.

-- Kernighan and Plauger, The Elements of Programming Style, 1978.

light relief:
An object oriented toaster
-- OO in excess
object orientation

The idea of object orientation is to chunk the design space into objects, each with some well defined behaviour and responsibility, communicating with each other by message passing. These objects can be grouped into classes in an inheritance hierarchy.

The chunking should allow systems that are easier to design -- because we can understand the chunks -- and to maintain -- because it is behaviour that changes most, and it has been localised, not spread throughout the entire program. (Think if all date behaviour was in one place: the Year 2000 problem could be solved with about one line of code!)

Inheritance hierarchies can be used in design to capture commonalities, and in implementation to provide code sharing. Object orientation claims to offer that holy grail of software reuse: You want yet another stack? Just get one from the Class Library.

light relief:
Dear Mr Architect
-- requirements statement
patterns and pattern languages

The class has turned out to be a bit too small to be the unit of reuse. We need ways to structure collections of objects working together to perform some task. High level descriptions of the collections are variously called Frameworks, or Patterns.

book reviews

general OO

Do we naturally use classification hierarchies? George Lakoff thinks not.


[Design Patterns]




XP : Extreme programming


I've programmed in a variety of languages: BBC Basic, C, Eiffel, Fortran, Java, occam, Prolog and Smalltalk (as well as less obviously 'general purpose' languages, like awk, LaTeX, Matlab, Postscript, and yacc). Although all these have there good points (yes, even Fortran!), Smalltalk is most definitely my favorite.


There are several Smalltalk FAQs around, although they are rather old, and unsupported.