Writer's Workhop A
|Bernhard Bürgin||Value with Quality|
|Frank Buschmann||Real-time Constraints as Strategies|
|Jim Coplien||C++ Idioms|
|Javier Galve-Francis, Julio Garcia-Martin & J. Manuel Burgos-Ortiz||An Approach to Algorithm Design by Patterns|
|Ullrich Koethe||Design Patterns for Independent Building Blocks|
|Dietmar Schütz||Reactive Cross-Check|
|Peter Sommerlad & Marcel Rüedi||Registry (in: Do-it-yourself Reflection)|
In a context where software performs calculations on the basis of incomplete or contradictory data, the end user might want to see not only the calculated results, but also information about the quality of the results. The Value with Quality pattern bundles a value together with its quality, and automates the propagation of quality to dependent results.
After describing the basic pattern, this paper focuses on some interesting consequences we encountered in applying the pattern in a project which calculates risk figures for financial instruments.
Shepherded by Dirk Riehle
[zipped Postscript (78k)] [plain Postscript (406k)]
The Real-time Constraints as Strategies design pattern decouples real-time specific constraints and behavior from the application service to which they apply. The application service is provided by a service class. Real-time related aspects are delegated to strategies which implement these in a specific manner.
Shepherded by Bob Hanmer
[zipped Postscript (40k)] [plain Postscript (143k)]
This paper attempts to do three things. The first is to re-cast the well-known idioms of Advanced C++ Programming Styles and Idioms in pattern form. The second is to organize these idioms, which until now have survived as independent and largely unrelated patterns, into a true pattern language. The third goal is to show that the patterns together (as a pattern language) attack what is metaphorically, conceptually, or actually a structural problem. These patterns do piecemeal construction of the structure of an inheritance hierarchy and the structure of the classes within it.
Shepherded by Steve Berczuk
[zipped Postscript (52k)] [plain Postscript (188k)]
This paper proposes some patterns to model in a simple way algorithm schemas. Taking as a reference the point of view provided by functional programming, the proposal allows algorithm schemas to be specified in the context of Object Oriented Programming, by using the design-pattern technology. We have succeded to define well-kown algoritm schemas (such as divide and conquer , backtracking or linear recursive schemas).
Shepherded by Bobby Woolf
[zipped Postscript (238 k)][plain Postscript (1.96 M)]
Object oriented languages allow one to model solutions in a variety of ways, from packaging state and algorithm together in pure objects to treating state and algorithm them as separate objects and everything in-between. As Cockburn puts it. "object technology is fundamentally a program-packaging technology that permits a continuum of function-only and function-plus-data packages". What is "right" in a particular case depends on the prevailing context and constraints.
Inheritance is often used in solutions because object oriented languages directly support it. However experience has shown that inheritance may have been oversold and that inheritance based solutions suffer from variety of problems. Other solutions, based on composition are more complex to assemble and maintain and must use home grown mechanisms for survival but they are often more responsive to change. Here, intransigent monolithic inheritance structures are broken down and re-glued in a less stringent way. Function and data are separated and dynamically loosely re-coupled to provide extra flexibility and robustness (usability over time).
The simple framework presented highlights some of the issues involved. Instead of adopting the mainstream inheritance approach, recursive algorithmic decomposition and indirection are substituted to gain flexibility, to influence runtime behaviour, and to achieve robustness in the face of change. These mechanisms which are resolved at runtime provide great freedoms can be seen as a move away from the straight jacket compiled, static inheritance based languages often impose. But they are appropriate only in given situations, suffering their own kinds of problems they are not a universal panacea. Surprisingly enough these mechanisms have their heritage in pre-Object solutions. Booch observes that these traditional techniques have their place in "bringing order to chaos".
Shepherded by Christa Schwanninger
[zipped Postscript (94 k)][plain Postscript (337 k)]
The pattern language presented in this paper aims at helping designers to develop reusable building blocks that can be plugged together as needed by the application to be built. The patterns are based on a discussion of the scales of software development which reveals important commonalties between otherwise very different design approaches. In particular, it is shown that extensive standardization is not a necessary prerequisite of reusability as long as requested interfaces are explicitly specified in a way which supports and simplifies interface adaptation. It is hoped that the presented design approach will be a small step towards the long envisioned.
Shepherded by Wolfgang Keller
[zipped Postscript (132 k)] [plain Postscript (1.15 M)]
The Reactive Cross-Check architectural pattern applies to interactive software systems which enable a human operator to supervise and control a potentially harmful real process and therefore must guarantee the correctness of the information displayed. By cross-checking computed results against duplicated components, the reactive cross-check provides safety through an "almost certain" detection of falsification of collected and visualized data.
Shepherded by Ward Cunningham
[zipped Postscript (13 k)] [plain Postscript (225k)]
contained in "Do-it-yourself Reflection patterns"
We wrote down this collection of design patterns, because they describe well-known stuff. They all have been used in building flexible systems or frameworks. We call them "do-it-yourself reflection", because they follow some of the principles of reflective systems, accessing program elements via data values (e.g. strings as names).
The four patterns are Property List, Registry, Anything and Configured Object Registry. Property List and Anything deal with flexibility in type and number of attributes or parameters. Registry and its special form Configured Object Registry provide mechanisms for managing global resources or objects in a systematic and flexible way.
Shepherded by Robert Hirschfeld
[zipped Postscript (53 k)] [plain Postscript (219k)]
|[EuroPLoP 98 Homepage]||
Last change: June 25th 1998