Plenary talk at Pattern Languages of Programs Conference, Allerton Park, Monticello, Illinois
This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.
About 40 participant in the room, laid out classroom style with a large screen projector
Why Design Patterns gives bad advice?
- 1. Time has changed? or
- 2. Should have known better in 1994, but we had a lot of reviewers back then
Had a workshop on Singleton pattern
- It’s one of the most misused patterns
- In early days, was shocked what people did with Singleton, people would say they used it 40 times
- Singleton is about global state, protecting yourself against global state, you don’t want to have much of that
- How could all of these people read the book, and completely misunderstand? This is why we write tests in programming
- This isn’t people how just use the pattern
Focus on Observer pattern (because didn’t get time to do other ones, may not use all of slides, will give talk again in a few days)
- A one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
- First named it as dependency, don’t remember how the name changed
Observer diagram:
- Think of bank robbers, with an FBI agent who is observing to see if they’re going to rob a bank
- Bank robbers hope there aren’t any FBI agents, but don’t really know
- Subject and observer (not typically called observable and observer)
- Subject can addDependent:, removeDependent: and changed:
- Observer can update:
- Subject will have a list of observers, but loose coupling
- Subject class doesn’t depend on FBIAgent class, but do have pointers from Subject class to Observer, and from FBIAgent to Observer
- It means every Mobster is carrying around a list of agents with him (not like real life, it’s the way programming is done)
Pattern has:
- Registration: often the hardest bugs to find, as forget to register or deregister something
- Notification: could be tricky to find bugs
- Update (which requires most code): bugs are easy to find and fix
Code example from the book
- class Subject
- class Observer {
- public: virtual ~Observer …
- private ….
In Java, they’re called Listeners, not Observers, code is different
- The argument to update is better defined, always as an event that changes
- There are subclasses of types of events, and EventListeners, each with own interface
- An EventListener can have more than one interface, e.g. Swing ComponentListener has componentResized, componentMoved, componentShown, componentHidden
Did we give hints in the book?
- Did we do this in Smalltalk? Yes, but we didn’t do it all in Smalltalk. There wasn’t events, but passed strings
- Avoiding observer-specific update protocols: the push and pull models. Pass more information.
- Pull means don’t send much information, let the observer ask for more information
- Push means observer gets more information
- Push assumes subject knows more about observier’s needs
- The push model makes observer less reusable. ?? Not really? If you had a mouse event, it can’t do much, it moves and button up and down. Everything you want to know about the mouse is in the event. But listener interface is Java is simple, everything is push. Then observer would become more reusable. So this published statement is WRONG.
We were writing up to our limits of understanding, without having looked at enough users.
- Every paper here tries to generalized, but don’t know how dangerous could be
We had Java listeners and tried to figure out how we missed that
Reality:
- Push model could make observers MORE reusable, by having specialized observer interfaces for particular kind of changes, e.g. mouse events
- VisualWorks did this, it didn’t implement fully because Smalltalk is dynamically bound
Thus, shows how we missed
- Java shows, in that they use library names that were written having read the Design Patterns
- Had observer pattern in Java, but then changed to listener
- Smalltalk is dynamically typed, but in C++ everyone would build own observer pattern, as no library at that time
- Requirement of wanting reuse, static typing
- Event bit was a good idea, not sure it hadn’t been done in systems before
Another idea missed: Data binding
- Talking with Erich Gamma, about how this is a lot about the observer pattern
- Erich though data binding was about not having a big monolithic model, but wanting to break up into smaller pieces
- Can observe a piece
- Observing a whole object will be big and complicated
- Will tend to have smaller and more usable interfaces
- Select from a list, some things will change, and the selection will change
- This gets away from explicitly having to send events: say there’s an event, and the property change will magically happen
- If have observables (model) change then the observers (view) will change
- Called data binding, but are setting up the observer interface
Consequences
- Don’t have to invoke update events explicitly
- Observers can be reused
- Main benefit is if there is a library, (which is less in C++ before there were libraries)
Not everything can be done this way
Use of Mediator with Observers
- Libraries take care of easy things in event handling, and then have to still do hard stuff with the Java libraries
- Have the mediator handle all of the special events
- In VisualWorks, it was called the application model
The book says that Mediator is related to Observer, but if you read the details, it says something else
- If you change this object, you want to update this other one, and then you need a constraint manager, and figure out how to broadcast this
- Most people are doing simpler things than this, but this is what was required in the graphical editors that John and Ralph were doing
Use of Adapter with Observer
- When listening to two different things
- If different, e.g. action listener for buttons
- Two buttons –> two listeners –> two inner classes
- Convert ActionPerformed into the name you really want: an adapter
- Then when have more listening interfaces, you get this event, but you have a library that wants to use something different, then have an adapter
Book doesn’t talk about either of those
Observer is a piece of MVC
- In book, say that MVC is a composite of views
- MVC is a strategy
- MVC uncouples? Observer more uncouples. It’s not about taking a big object and breaking it up into small objects
- It says build standard observables
- A toolkit of pieces, binding them together
- Observer could be used with a big object, which tells you changes in the 57 different ways
- Model – View – Controller, for a Smalltalk program, Controller isn’t in between the Model and the View, although frameworks for web tend to do it this way
People tend to be lumpers or splitters
- Ralph is a lumper
- George Lakoff in Fire, Dangerous Things talks about how people make distinctions, e.g. chairs, some with wheels, they have four legs, if it has 3 legs, when do you start calling it a stool; if they’re mounted on a rail and can’t move it, is it chair? As you move farther from the ideal, is the same thing, or do you need a new name?
Iterator pattern
- Idea wasn’t to ask for the next item
- Object has a lot of structure, ask it to come back with an iterator as an object class
- Simple, you could do a fork
- Book writes about internal iterators and external iterators, for closure
- For each and do
- If you have closures, you will do a lot of iterations: Smalltalk, Groovy
- In Groovy, have collect, findAll
- Can define on streams, not just on collections
- Standard Smalltalk libraries don’t have streams
- Didn’t talk about this in the book, should have
- Javascript has map and filter
The book didn’t say
- A Stream is a kind of iterator (wasn’t it obvious?)
- You can define map, filter and reduce on your iterators. If you language has closures, you should (although it’s pain, so often people don’t do it)
Reactive programming: Iterator meets Observer
- This could be what Rebecca was saying about Javascript
- Think of a “subject” as an EventStream, then an Observer is a function on EventStream (maybe it produces a display)
- It eliminates the need to keep state to synchronize different event streams
- Makes error handling easier
- Reduces memory leaks
Asynchronous streams:
- concatAll
- Not deterministic, don’t know how long it will take to get to the end of the list
Mouse Drags Collection
- Ask an element for a stream of mouse down events
- For each mouse down event, tell the document (that has mouse moves) to take mouse moves until the mouse up event
- Gives a list of mouse movements, then concatAll of them gives mouse movement locations, so image is moved to a stream of locations
There’s a library, search on “reactive extensions”
When you treat a set of observables over a stream of events, you eliminate the need to write mediators, solves problems with race conditions
Things that didn’t talk about in the book
- Listener, didn’t think about that 20 years ago
- Should have talked about events, as having event-objects, people were doing that but didn’t know it was interesting
- More concerned about push versus pull and seeing that it wasn’t true
- Just getting into looking at relationships between patterns, that could have happened if had another six months, but had a deadline
- World has moved on
- Interesting trying to get a handle at a point of time
- Lisp people said they’ve done that, but book isn’t the only place where Lisp people have been ignored.
In brief. David Ing. 