Tuesday, June 8, 2010

Mastering Design Patterns

6/8/2010
Instructor: Robert Martin

...A discussion on Hubble and the expansion and age of the universe

Design Patterns book 1995 "Gang of Four" GoF95

Design patterns are encoded knowledge given a name and a canonical form: once you know/recognize it you can stop thinking about it

A design pattern is a solution to a recurring problem

Abstract Server pattern: so simple it's not in the books
or polymorphism pattern

Clients and the interfaces they used get grouped together, NOT grouped by hierarchies

Adapted Server pattern
Adapter allows you to "adapt" a class you dont own the source code of
Can combine incompatible interfaces/convert one interface to another

A delegation relationship is when the Adapter simply passes on the call to the connected interface

Class form of the adapter pattern: the adapter inherits from both the interface and the server

Template Method Pattern (or write a loop once)
Strategy Pattern

It is polite to change the name of the class to include the design pattern name to aid recognition for the reader

Data structures have well known data and very little behavior (methods)
Objects have well known behaviors and very little known data

...a discussion on the early expansion of the universe shortly after the big bang

State Pattern
How do we implement finite state machines?
Implementing in a huge nested switch statement is very hard to maintain

SMC (google it): implementation of state machine classes is generateble if you know the state event/action table
Parsers, network protocols, GUIs, are FSMs

Command Pattern
Remarkably simple but the repercussions are enormous
A way to decouple what gets done from who does it
A sensor can be decoupled from the command it calls
Can also be used to store a list of commands and "undo" them as necessary
Or transaction commands in a DB which can be executed later during downtime
Decoupling what gets done from WHEN it gets done
A list of commands (some of which add new commands to the list) can be used for multitasking/task switching on a single stack (called run to completion) There's no blocking: if a command needs to wait for an event, it must clone itself and put it on the list

...a discussion on stars and supernovas/hypernovas

Composite Pattern
Similar to the command pattern & very simple
A way to take many objects and treat them as one
The composite exists at a lower level so the higher level model is not affected
"take all details and shove them down as far as you can"
dont expose details at the highest levels
If you're doing to treat a composite of objects identically, then a composite is useful. If you're going to scan the objects and treat them different, the composite pattern cannot be used

Proxy Pattern
Can be used to create a "proxy" class that hides dependencies and isolates an application from (for instance) a DB. The proxy database interface layer depends on the app and the DB: the app does not depend on the DB because the dependencies have been inverted
Can also be used for cross-process communication
However: the proxy objects are complicated & difficult to maintain (but at least all your complications are isolated in the proxy)

Observer Pattern
(...a discussion on leap years and leap seconds and the changing rotation of the earth)
Allows an object to notify multiple dependent objects every time it changes state
small changes can be pushed thru the notify() function
larger changes need to be pulled from the dependent object when they are needed
sometimes hints can be passed to narrow down where the change occurred
Can build systems that watch & react to other objects as they change: a cool form of indirection until you have to debug it.
Comes up a lot in GUI's, callbacks, listeners, MVC

MVC was probably the first design pattern to get a name (70s)
The input/process/output split is the same, but the object/observer relation is not the same as the original smalltalk version of MVC
What does MVC mean anymore? not much

Document View Pattern is similar to MVC
merges the view/controller

Model View Presenter
How do you write tests against a GUI?
Move complexity out of the view into a presenter
Presenter observes the model
View queries the presenter
Presenter restructures the data from the model so it is presentable
View is stupid
Presenter knows nothing about the GUI: it is creating data structures
Now you can test the presenter! And the view is so stupid you don't need to test it, or the test is trivial

No comments:

Post a Comment