By Ellen Domb and John W. Stamey
Altshuller's 40 Inventive Principles have strong links to the structural design patterns attributed to Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (the Gang of Four) in Design Patterns: Elements of Reusable Object-Oriented Software.
The understanding of concepts is improved when we can describe a not-so-familiar concept or framework in terms of one with which we are familiar. Additionally, new insight and understanding can be gained from the metaphorical cross-pollination that happens when describing one framework with another.
We will describe a subset of the 23 Design Patterns developed by the Gang of Four  as instances of problem solving principles found in Genrich Altshuller's Theory of Inventive Problem Solving (TRIZ). An early observation of the similarity between design patterns and TRIZ is that both systems are actually sets of heuristics, derived from observations of successful solutions to common problems.  Further analysis finds strong links between the Structural Patterns of the Gang of Four and a specific set of TRIZ principles.
Altshuller and his colleagues developed the 40 Principles by analyzing thousands of patents. They identified 39 System Characteristics (or features). The popular Contradiction Matrix shows the principles that are most frequently used to solve problems for contradictions between any two of the System Characteristics. [3, 4]
For example, imagine a mechanical problem in which the strength of a system gets better by adding more material, but the weight gets worse. The matrix tells us that principles 40, 26, 27 and 1 are most frequently used to solve the problem arising from the tradeoff of increased strength at the cost of more weight:
Computer scientists have long known the forces of time and space (two System Characteristics) are usually at odds with each other. The general problem is that as the System Characteristic of time decreases (gets better), the System Characteristic of space increases (gets worse). Conversely, as the System Characteristic of space decreases (gets better), the System Characteristic of time decreases (gets worse).
An interesting example of the time-space tradeoff comes from Jean-Louis Lassez.  A problem with databases is that the more information they store, the slower they become. However, the more information we have, the more likely we are to find the answer to an important question. Identifying "access to more answers and information" as the Volume of a Static Object (System Characteristic 8) and identifying "increased the time necessary to find an answer" with Time Action of a Stationary Object (System Characteristic 16), we examine the 39x39 contradiction matrix for the solution. The intersection of Time Action of a Stationary Object along the horizontal axis (getting worse) and Volume of a Static Object along the vertical axis worsening (getting better) shows the three most popular solutions for this contradiction:
Principle 34 includes the following statement: "After completing its function or becoming useless, an element of an object is rejected (discarded, dissolved, evaporated, etc.) or modified during its work process." This description contains the essence of the definition of a cache, which is a common solution to the initial problem with databases. Examining the more general issue of taking more time (getting worse) to sort through an abundance of information (getting better), the TRIZ solution found in Principle 34 nicely describes the idea of a FAQ (list of Frequently Asked Questions), another example of a cache.
The Gang of Four's 23 Design Patterns have become standard implementation practices in software engineering best practices. The seven Structural Design Patterns, at their highest conceptual levels, have strong links to the 40 Principles of TRIZ. In the next section, we briefly describe each of the structural design patterns, along with the TRIZ Principle(s) that best describe the design patterns.
The adapter pattern converts the interface of a class into one that an object would expect. In this way, objects can work together because incompatible interfaces are avoided. Suppose we have classes C and D. An object instantiated from class D (d) wishes to use an object instantiated from class C (c). However, the interface to c is not what d expects. The adapter pattern is a way to create a compatible interface for d to c.
TRIZ Principle 24 – Mediate or negotiate a temporary link between incompatible parties. This is best done when there are conditions that are incompatible or mismatched with related functions, events or conditions.
There are times when we have the notion of an abstract class (such as TVremoteControl) that provides us a way to operate on something with a concrete implementation (such as a TV). The TVremoteControl class has abstract actions (methods) such as on, off, setStation, getNextChannel, etc. In the real world, we can add, delete or change these TVremoteControl actions. Concrete TV sets (implementations) can change, as well as vary widely across different manufacturers. The bridge pattern class allows us to form a relationship between an abstract class that interacts with a concrete class. We see the "HASA" relationship between the abstract class (TVremoteControl) and the concrete class (TV). The reason for this is that there are many different TV implementations. TVremoteControl is in a one-to-many relationship with all of the types of TVs (different objects) for which it works.
TRIZ Principle 2 – Extraction separates useful or harmful parts or properties of a system. Here, we separate the abstract concept from the physical implementation of a system, so that we can work on each separately.
There are several lists to use. Each of the lists can be in a different format. It is useful to create one interface through which items in the different lists can be accessed. A second interface is created to move through lists (in the format provided by the list interface). This interface, through which list items are accessed, is called an iterator. The underlying representation (implementation) of the list is of no consequence, the returning of the next list item being of primary importance.
TRIZ Principle 6 – Universality promotes uniformity of feature, uniform use of an object for different purposes, or applying the same requirements or features for different objects, situations or actions.
The decorator pattern dynamically adds functionality to an object. Using the decorator pattern is a way to avoid creating subclasses (child classes) to provide extended functionality. The decorator pattern begins with a superclass of a particular component, C. The object we will "decorate" is a subclass of C, we will call c. The decorator object, d, references variables in object c. A subclass of the decorator creates the additional functionality provided by the decorator class.
TRIZ Principle 7 – Nesting applies where one object fits inside another, or passes through another.
TRIZ Principle 30 – Flexible Membranes or Thin Films prescribes the replacement of traditional constructions with constructions of thin film or flexible membranes. Also, an object may be isolated from its environment by a thin film.
Given a collection of interfaces, a client (user) should only have to deal with one unified interface system when trying to access data. The highest level of interfaces is called the facade pattern. It is a direct implementation of the Law of Demeter, which encapsulates the Principle of Least Knowledge ("friends only talk with friends").
TRIZ Principle 5 – Consolidation brings functions or parts of a system into a relationship that creates a new outcome. One example is combining the ability for one player to play multiple formats (DVD, mp3, etc.). For the façade pattern, one interface acts as a gateway to many others.
There are times when you need to have thousands of instances of an object. Each object is relatively simple, usually calling a few methods. An example of this would be a web-based word processor that has perhaps 2,560 locations for characters to be placed. Characters either appear or disappear (two methods). The flyweight pattern prescribes a manager to organize each of the small objects (configuring the characters into 80 per column and 32 rows per page). The character objects are then responsible for their own management (showing or not showing a letter, number, symbol or blank).
TRIZ Principle 17 – Transition into a New Dimension suggests changing the orientation of a system by adding a dimension. This new dimension can place less strain onto an existing dimension or it can add a controlling dimension (like the flyweight pattern).
Like its dictionary namesake, the proxy pattern is used to control access to an object. As an example, there are times when a user might request an image to be displayed. If the size of the image file is large, then it might take a while for the image (perhaps a Flash animation) to appear. Good usability practices suggest that a small "Loading" animated icon show until the larger Flash file is loaded in memory and can play. Enter the proxy pattern to do just that – play the "Loading" icon until the Flash images is ready to display, then display the image.
TRIZ Principle 35 – Parameter Changes suggests changing an object's physical state (e.g., to a gas, liquid or solid). Change the concentration or consistency. Change the degree of flexibility. Change the temperature. Change any parameter that will improve the situation. (Frequently, identifying the correct parameter is the key to breakthrough problem solving.)
TRIZ Principle 36 – Phase Transition suggests using phenomena occurring during phase transitions (e.g., volume changes, loss or absorption of heat, etc.). In data analysis, a Fourier transform or other mathematical transformation can be regarded as a phase change.
Research continues on mapping the 23 Design Patterns into the 40 Principles of TRIZ. An advantage of this approach is the ease of communicating complex solutions through the not-so-complex language of the TRIZ Principles.
The authors would like to thank Dr. Jean-Louis Lassez of Coastal Carolina University for his helpful comments in the development of this paper.
This paper is an expanded version of a presentation at the Association for Computing Machinery Special Interest Group on Documentation Conference, October 2006.
Ellen Domb is the founder and principal TRIZ consultant of the PQR Group. She is also the founding editor of The TRIZ Journal and a commentator for Real Innovation. Contact Ellen Domb at ellendomb (at) trizpqrgroup.com or visit http://www.trizpqrgroup.com.
John Stamey is a professor in the Department of Computer Science at Coastal Carolina University. Contact John W. Stamey at jwstamey (at) coastal.edu.