Patterns: building blocks for object-oriented architectures3

Reporter's note: this is my own choice of how best to present our work in the space available. A brief account precedes a list of patterns, and the polished version of one example in full. Work process Call-stress definite outcomes; insist on use of fixed template; give examples Beforehand-circulate all accepted patterns to participants Arrival-music, badges, a vigorous game Divergent phase-a guided fantasy on " powerful uses of patterns in the workplace, " leading to impressionistic posters by small groups, on the function of patterns. Working-Relining of patterns, in small groups where the author was interviewed and then members worked on both the pattern and the writeup. Integrating-authors made posters about their patterns, on flipchart sheets, illustrating them graphically and attaching their revised writeups. Then we walked around looking at each others' work, and discussing it. Closure-a circle where we each said something we had learned during the day, and agreed to circulate our revised patterns. This structure is successful because of (a) commonality of interest and commitment, through submitting a pattern in the agreed format, (b) commonality of background through having read the circulated patterns, (c) creation of a safe and motivating atmosphere by the leaders, (d) worthwhile tasks to do, and (e) sharing of results. Note especially that we had no presentations at all during the workshop-1 believe that the passivity Addendum to the Proceedings OOPSLA'93 and inequality they force on an audience is very hard to transform into productive work, and the enjoyment that such work brings. Short description: Whenever the variation between systems or subsystems or versions is in the way of carrying out some operation, make the operation into a strategy object. Contrast this with making it a member function. Short description: For a collection, let each member do as much as it can; limit the behavior of the overall collection to things that its parts cannot do well. Short description: A 'front-end' hierarchy of classes is developed, knowing that in any given application, nearly all objects will actually be instances of subclasses of EACH class in the hierarchy. By using multiple inheritance plus Factories, applications may create a parallel hierarchy of 'back-end' classes that reuse and build off front-end functionality, without otherwise altering the front-end.