Patterns

1
Patterns

• Things that repeat.
• Solutions to a problem in a context.
• Patterns for coding/low-level design /
  architecture/user interface/problem domain

2
Coding patterns

• Smalltalk Best Practice Patterns
• Kent Beck
• Prentice-Hall, 1997

3
OOD patterns

• Design Patterns Elements of Reusable
  Object-Oriented Software
• Erich Gamma, Richard Helm, Ralph Johnson, John
  Vlissides
• Addison Wesley, 1995.

4
Architectural Patterns

• Pattern-Oriented Software Architecture
• F. Buschmann, R. Meunier, H. Rohnert,
  P.Sommerlad, M. Stal
• Wiley, 1996
• http//www.cs.wustl.edu/schmidt/POSA/

5
Business Software

• Patterns of Enterprise Application Architecture
• Martin Fowler et. al.
• Addison-Wesley, 2002
• http//www.martinfowler.com/books.htmleaa

6

• Domain Driven Design
• Eric Evans
• Addison-Wesley, 2004
• http//domaindrivendesign.org/

7
Patterns

• Solution to a problem in a context
• Best practice.
• Things experts do

8
Replication

• Keep a copy of data on serveral computers.
• Every time one computer makes a change, make a
  change on the replicas, as well.

9
Peer-to-peer games
GUI
GUI
broker
events
events
Model
Model
10
Peer-to-peer games

• Event-oriented, not object-oriented
• Easy to convert from single-cpu to distributed
• Easy to debug
• Easy if only one person can make a move at once
• Must synchronize simultanious moves
• Hard to make secure

11
Fault tolerance

• Primary and backup
• Messages go to everyone, only primary responds
• If primary doesnt respond, backup takes over

12
Croquet

• 3D virtual world
• Rendering takes place on local machine
• Events must be synchronized, then all copies of
  the world are changed
• Opencroquet.org

13
Persistence

• Keep everything in memory
• Replicate for backup
• Synchronize with a single lock
• Very fast
• No SQL
• Must fit in memory

14
Summary

• Design is hard
• Design is about tradeoffs
• There is no perfect solution, just a solution
  whose defects dont bother you.
• Patterns are no panacea, but fit people.

15
Smalltalk Coding Patterns

• mostly from
• Smalltalk Best Practice Patterns
• Kent Beck
• Prentice-Hall, 1997

16
The Book

• 1. Introduction (Read
• 2. Patterns (Read
• 3. Behavior (Today
• 4. State (Next time
• 5. Collections (Last week
• 6. Classes (Next time
• 7. Formatting (Next time

17
Coding Standards

• Standards
• improve communication
• let code be the design
• make code more habitable
• change

18
Coding Standards for Smalltalk

• Variables have no types
• Names can be any length
• Operations named with keywords
• Pretty printer

19
Names

• Names should mean something.
• Standard protocols
• Object (printOn, )
• Collection (do, add, atput, size)
• Standard naming conventions

20
Intention Revealing Selector

• Readability of message send is more important
  than readability of method.
• Name should specify what method does, not how.

21
Method Names

• If there is already a standard name, use it
  instead of following these rules.
• Three kinds of methods
• change state of receiver
• change state of argument
• return value from receiver

22
Change state of receiver

• method name is verb phrase
• - translateBy
• - add

23
Change state of argument

• Verb phrase ending with preposition like on or
  to.
• - displayOn
• - addTo

24
Return value from receiver

• method name is noun phrase or adjective, a
  description rather than a command
• - translatedBy
• - size
• - topLeft

25
Method Names

• Specialized names for specialized purposes.
• Double-dispatching methods
• Accessing methods
• Query methods
• Boolean property setting
• Converter methods

26
Accessing Methods

• Many instance variables have accessing methods,
  methods for reading and writing them.
• Accessing methods come in pairs.
• name, name
• width, width
• x, x

27
When to use Accessing Methods

• Two opinions
• Always, including an objects own instance
  variable
• lazy initialization, subclassing is easier
• Only when you need to use it.
• better information hiding

28
Query Method

• Methods that return a value often describe the
  type of the value because they are noun phrases.
• Query methods are not noun phrases, but are
  predicates. How can we make the return type
  clear?

29
Query Method

• Prefix every query method with "is".
• isNil
• isControlWanted
• isEmpty
• Put query methods in protocol testing

30
Boolean Property Setting

• Don't make accessing methods whose only argument
  is a boolean.
• Create two methods beginning with be". (or
  make) Add "toggle" if necessary.
• beVisible / beInvisible / toggleVisible
• beDirty / beClean

31
Converter Method

• Often you want to return the receiver in a new
  format.
• Prepend "as" to the name of the class of object
  returned.
• asSet (in Collection)
• asFloat (in Number)
• asComposedText (in Text)

32
Converter Constructor Method

• A class can get cluttered with converter methods
  that have no relationship with its main
  responsibility.
• Make a Constructor Method in the target class
  that takes the object to be converted as an
  argument.
• Date fromString 09/10/01

33
Constructor Method

• Class methods that create instances are in
  category "instance creation methods".
• Creation followed by initialization is the most
  flexible.
• - Point new x 0 y 0
• Important to preserve invariants and avoid
  ill-formed objects.

34
Constructor Method

• Instance creation methods should create
  well-formed instances. Pass all required
  parameters to them.
• - Point x 0 y 0
• - SortedCollection sortBlock aBlock
• - Set new

35
Constructor Parameter Method

• How should a Constructor Method initialize new
  object?
• Separate setters are most flexible
• x aNumber y anotherNumber
• self new x aNumber
• y anotherNumber
• Must maintain invarients.

36
Creation Parameter Method

• Provide a single method that sets all the
  variables. Preface its name with "set", then the
  names of the variables.
• x aNumber y anotherNumber
• self new setX aNumber y anotherNumber

37
Shortcut Constructor Method

• It is verbose to keep mentioning class names, and
  they are duplicated.
• Point x width y height
• width _at_ height

38
Composed Method

• How big should a method be?
• Write methods that perform one identifiable task.
• Few lines per method.
• Consistent level of abstraction.
• Minimizes number of methods you have to change in
  subclass.
• Minimizes code copying in subclass.

39
Composed Method Usage

• Top down
• - self input process output
• Bottom up
• - common expressions
• - long loop bodies
• - comments
• From client - two or more messages to another
  object is suspicious

40
Methods from Comments

• Comments indicate "identifiable task"
• If you need to comment a block of code, it
  probably should be a separate method.
• Turn method comment into method name.

41
Reversing Method

• Good code has a rhythm that makes it easy to
  understand. Code that breaks the rhythm is
  harder to read and understand.
• Point
• printOn aStream
• x printOn aStream.
• aStream nextPutAll _at_.
• y printOn aStream

42
Reversing method

• Point
• printOn aStream
• aStream
• print x
• nextPutAll _at_
• print y

43
Reversing method

• Make a method on the parameter.
• Derive its name from the original message.
• Take the original receiver as a parameter.
• Implement the method by sending the original
  message to the original receiver.

44
Method object

• What do you do about a method that is too big but
  that cant be decomposed because of all the
  temporary variables that are used?
• Turn method into a class. Temporary variables
  and arguments become instance variables. Then
  you can decompose the method.

45
Example of Method Object

• In class Class
• readNewSubclassOn aCodeReader in aNameSpace
• fullName numInstVars numMetaInstVars
• metaclassFormat allMetaclassInstVars
  metaclassInstVars classFormat allClassInstVars
  classInstVars newMeta class bookkeepingInfoStart
  bookkeepingInfoSize
• fullName aCodeReader readByteSymbol.

46

• aCodeReader fileFormat gt 10
• ifTrue
• metaclassFormat aCodeReader readLong.
• numMetaInstVars aCodeReader readLong.
• allMetaclassInstVars aCodeReader
  readByteStringCollection.
• metaclassInstVars allMetaclassInstVars
• copyFrom allMetaclassInstVars size -
  numMetaInstVars 1
• to allMetaclassInstVars size.
• classFormat aCodeReader readLong.
• numInstVars aCodeReader readLong.
• allClassInstVars aCodeReader
  readByteStringCollection.
• classInstVars allClassInstVars copyFrom
  allClassInstVars size - numInstVars 1 to
  allClassInstVars size
• ifFalse
• metaclassFormat aCodeReader readLong.
• metaclassInstVars aCodeReader
  readByteStringCollection.
• numMetaInstVars metaclassInstVars size.
• classFormat aCodeReader readLong.
• classInstVars aCodeReader readByteStringColle
  ction.
• numInstVars classInstVars size.

47

• Make class NewSubclassReader, a subclass of
  Object.
• Make instance variables for arguments, receiver,
  and temporaries aCodeReader aNameSpace
  superclass fullName numInstVars numMetaInstVars
  metaclassFormat allMetaclassInstVars
  metaclassInstVars classFormat allClassInstVars
  classInstVars newMeta class

48

• readNewSubclassOn aCodeReader in aNameSpace
• (NewSubclassReader on aCodeReader in
  aNameSpace) readNewSubclass

49

• readNewSubclass
• self initializeClassInformation.
• self makeNewMetaclass.
• self makeNewClass.
• self isNewClassIncompatibleWithSuperclass
  ifTrue
• CodeReader invalidClassFormatSignal
• raiseWith fullName
• errorString ' ', fullName.
• self checkShapeChange.
• self readSubclassInfoFromCodeReader.
• class

50
Extract method

• Turn an expression into a method of its own
• References to arguments or temporaries turn into
  arguments of new method.
• References to instance variables dont change
• in the expression can be a problem

51
Execute Around Method

• Pairs of actions that must be taken together
• Open file / close file
• Start tag / end tag
• aCursor showWhile
• aFile openDuring aThing printOn aFile

52
How to make a good program

• Make it run the test cases
• Make it easy to understand, simple, follow coding
  standards, and eliminate duplication.
• It is OK to get the tests to run first, and then
  worry about making your program readable.
• It is OK to make sure your program is always
  readable.

53
How to make a good program

• It is not OK to hand in programs that are hard to
  understand, that dont follow standard patterns,
  and that have a lot of duplication.