Patterns Protect from Change Rule: if something is going to change, make it an object. Strategy: make algorithm an object so it can change State: make state-dependent behavior an object so it can change Iterator: make the way you iterate over an aggregate an object so it can change Facade: make a subsystem an object so it can change Mediator: make the way objects interact an object so it can change Factory: make the classes of your products an object so it can change

Patterns lead to standard interfaces Decorator, Composite, Proxy Introduce new objects with same interfaces as old but that add a feature / represent a group / represent a remote object Adapter Facade

Smalltalk features impact patterns Iterator – blocks Proxy – doesNotUnderstand: Command – blocks, perform: Prototype – classes as objects Bridge – dynamic typing?

Patterns and refactoring Can think of any design pattern as a “big refactoring” Introduce design patterns when you know you need them, not when you think you might need them Refactoring to Patterns by Joshua Kerievsky

Command ConcreteCommandexecuteundo Commandexecuteundo Receiver Invoker Client

Refactoring to Command Client has number/string/… that it passes to receiver, which has a case statement to decode it. Make a method for each case. Client passes selector for method (symbol) and receiver has self perform: aCommand Make each method a command class. Client creates instance and receiver has aCommand execute: self

Composite Component Container Children CompositeLeaf Composite and Component have the exact same interface. interface for enumerating children interface for enumerating children Component implements Children() by returning empty set Component implements Children() by returning empty set interface for adding/removing children? interface for adding/removing children?

Refactoring to a Composite CompoundLeaf Missing abstract class Missing leaf classes Element Class2Class3Class1 * *

Façade Provide a unified interface to a set of interfaces in a subsystem. Define a higher-level interface that makes the subsystem easier to use. Facade

Design patterns and refactoring Complexity is the death of software Think of “before” and “after” Design pattern can be a smell

Design Pattern summary Larger conceptual unit than class/message Vocabulary Expert knowledge Not magic – design tradeoffs Not completely language independent Use wisely - experiment

Exceptions An example of reflection Using objects to implement a language

Error-handling How do you signal an error? 1) Special return value 2) Evaluate error block (map at: key ifAbsent: [ ^map at: key put: (Set with: value)]) add: value 3) Exceptions

Exceptions Module will “raise an exception” Client will “handle an exception” In Smalltalk, exception is an object. Implementation uses contexts.

Contexts context stores temporaries, method arguments, program counter, and return address thisContext gives method its own context used by debugger, exception handling, processes, backtracking

Contexts PolylineFiguredisplayOn:CompositeFiguredisplayOn:DrawingdisplayOn:

Key Idea Program handles a particular error signal. [ object doWork ] on: Error do: [ :theException |... ] Server raises the same class of exception. Error signal

Exception Handling [ x / y ] on: ZeroDivide do: [ :theException | theException return: 0] / signals an error by ZeroDivide signal

Exception Handling The ”signal" method of Exception 1) creates an Exception, 2) looks on the stack for an on:do: message that uses the class or its subclass, and 3) evaluates the second argument of the on:do: message with the Exception as the argument.

Exceptions Exceptions can have an error string. Some implementations give them other arguments, but that is not part of the standard. Exception signal signal: aMessageString

Exception Protocol resume:- return from message that signaled exception retryUsing: - abort exception handler and reevaluate its exception block return:- return from block protected by active exception handler

Multiple Handlers Exception travels down stack of contexts, looking for a handler to the exception. It evaluates the handle block of the first match.... E raise on: E do:... on: E: do:

Exception Protocol reject will cause an Exception to look for the next handler. return will throw away all contexts above the handler.

Exception Hierarchy Handler for one exception will catch all subclasses, as well. Exception Error ArithmeticError MessageNotUnderstood KeyNotFoundError

Unwind Protection Problem: program can get blown away by an exception while it is in the middle of making delicate changes. This is a problem with returns in general, even without exceptions.

Unwind Protection Solution: [self dangerousCode] ifCurtailed: [self cleanUp] The cleanup block is used if the execution stack is cut back for any reason.

Unwind Protection ensure: evaluates the cleanup block after the receiver is evaluated. Semaphore critical: aBlock self wait. aBlock ensure: [self signal]

An example processFile: aFile "Read a catalog card from the first comment. Trap and report all errors." aFile isReadable ifFalse: [^self]. [self processWithErrorsFile: aFile] on: Error do: [:ex |... ]

The Handle Block [:ex | Transcript show: ex errorString. Transcript show: ' for ', aFile asString. Transcript cr. Dialog confirm: ex errorString. ex return ]

processWithErrorsFile: aFile "Read a catalog card from the first comment." | aStream string document | aStream := aFile readStream. [...] ensure: [aStream close]

If we encounter an error [Transcript show: 'bad file ', aFile asString. ^Transcript cr]. Also, system generates errors for files that are not readable.

Halt halt "This is the typical message to use for inserting breakpoints during debugging. It behaves like halt:, but does not call on halt: in order to avoid putting this message on the stack. Halt is especially useful when the breakpoint message is an arbitrary one." Halt signal

Exception handling important in developing reusable libraries. Squeaks reflective use of contexts makes it possible to implement exception handling as a class library.