Mon, 11 Sep 2006
Design patterns of 1972
“Patterns” that are used recurringly in one language may be invisible or trivial in a different language.
Extended Example: “object-oriented class”
C programmers have a pattern that might be called “Object-oriented class”. In this pattern, an object is an instance of a C struct.
struct st\_employee\_object \*emp;
Or, given a suitable typedef:
EMPLOYEE emp;
Some of the struct members are function pointers. If “emp” is an object, then one calls a method on the object by looking up the appropriate function pointer and calling the pointed-to function:
emp->method(emp, args...);
Each struct definition defines a class; objects in the same class have the same member data and support the same methods. If the structure definition is defined by a header file, the layout of the structure can change; methods and fields can be added, and none of the code that uses the objects needs to know.
There are a bunch of variations on this. For example, you can get opaque implementation by defining two header files for each class. One defines the implementation:
struct st\_employee\_object {
unsigned salary;
struct st\_manager\_object \*boss;
METHOD fire, transfer, competence;
};
The other defines only the interface:
struct st\_employee\_object {
char \_\_SECRET\_MEMBER\_DATA\_DO\_NOT\_TOUCH\[4\];
struct st\_manager\_object \*boss;
METHOD fire, transfer, competence;
};
And then files include one or the other as appropriate. Here “boss” is public data but “salary” is private.
You get abstract classes by defining a constructor function that sets all the methods to NULL or to:
void \_abstract() { abort(); }
If you want inheritance, you let one of the structs be a prefix of another:
struct st\_manager\_object; /\* forward declaration \*/
#define EMPLOYEE\_FIELDS \\
unsigned salary; \\
struct st\_manager\_object \*boss; \\
METHOD fire, transfer, competence;
struct st\_employee\_object {
EMPLOYEE\_FIELDS
};
struct st\_manager\_object {
EMPLOYEE\_FIELDS
unsigned num\_subordinates;
struct st\_employee\_object \*\*subordinate;
METHOD delegate\_task, send\_to\_conference;
};
And if obj is a manager object, you can still treat it like an employee and call employee methods on it.
This may seem weird or contrived, but the technique is widely used. The C standard contains guarantees that the common fields of struct st_manager_object and struct st_employee_object will be laid out identically in memory, specifically so that this object-oriented class technique can work. The code of the X window system has this structure. The code of the Athena widget toolkit has this structure. The code of the Linux kernel filesystem has this structure.
Rob Pike, one of the primary architects of the Plan 9 operating system (the Bell Labs successor to Unix) and co-author (with Brian Kernighan) of The Unix Programming Environment, recommends this technique in his article “Notes on Programming in C”.
This is a pattern
There’s only one way in which this technique doesn’t qualify as a pattern according to the definition of Gamma, Helm, Johnson, and Vlissides. They say:
A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.
Their definition arbitrarily restricts “design patterns” to addressing recurring design problems “in object-oriented systems”, and to being general arrangements of “objects and classes”. If we ignore this arbitrary restriction, the “object-oriented class” pattern fits the description exactly.
The definition in Wikipedia is:
In software engineering, a design pattern is a general solution to a common problem in software design. A design pattern isn’t a finished design that can be transformed directly into code; it is a description or template for how to solve a problem that can be used in many different situations.
And the “object-oriented class” solution certainly qualifies.
Codification of patterns
Peter Norvig’s presentation on “Design Patterns in Dynamic Languages” describes three “levels of implementation of a pattern”:
Invisible
So much a part of language that you don’t notice
Formal
Implement pattern itself within the language
Instantiate/call it for each use
Usually implemented with macros
Informal
Design pattern in prose; refer to by name, but Must be reimplemented from scratch for each use
In C, the “object-oriented class” pattern is informal. It must be reimplemented from scratch for each use. If you want inheritance, you have to set it up manually. If you want abstraction, you have to set it up manually.
The single major driver for the invention of C++ was to codify this pattern into the language so that it was “invisible”. In C++, you don’t have to think about the structs and you don’t have to worry about keeping data and methods private. You just declare a “class” (using syntax that looks almost exactly like a struct declaration) and annotate the items with “public” and “private” as appropriate.
But underneath, it’s doing the same thing. The earliest C++ compilers simply translated the C++ code into the equivalent C code and invoked the C compiler on it. There’s a reason why the C++ method call syntax is object->method(args…): it’s almost exactly the same as the equivalent code when the pattern is implemented in plain C. The only difference is that the object is passed implicitly, rather than explicitly.
In C, you have to make a conscious decision to use OO style and to implement each feature of your OOP system as you go. If a program has fifty modules, you need to decide, fifty times, whether you will make the next module an OO-style module. In C++, you don’t have to make a decision about whether or not you want OO programming and you don’t have to implement it; it’s built into the language.
Sherman, set the wayback machine for 1957
If we dig back into history, we can find all sorts of patterns. For example:
Recurring problem: Two or more parts of a machine language program need to perform the same complex operation. Duplicating the code to perform the operation wherever it is needed creates maintenance problems when one copy is updated and another is not.
Solution: Put the code for the operation at the end of the program. Reserve some extra memory (a “frame”) for its exclusive use. When other code (the “caller”) wants to perform the operation, it should store the current values of the machine registers, including the program counter, into the frame, and transfer control to the operation. The last thing the operation does is to restore the register values from the values saved in the frame and jump back to the instruction just after the saved PC value.
This is a “pattern”-style description of the pattern we now know as “subroutine”. It addresses a recurring design problem. It is a general arrangement of machine instructions that solve the problem. And the solution is customized and implemented to solve the problem in a particular context. Variations abound: “subroutine with passed parameters”. “subroutine call with returned value”. “Re-entrant subroutine”.
For machine language programmers of the 1950s and early 1960’s, this was a pattern, reimplemented from scratch for each use. As assemblers improved, the pattern became formal, implemented by assembly-language macros. Shortly thereafter, the pattern was absorbed into Fortran and Lisp and their successors, and is now invisible. You don’t have to think about the implementation any more; you just call the functions.
Iterators and model-view-controller
The last time I wrote about design patterns, it was to point out that although the movement was inspired by the “pattern language” work of Christopher Alexander, it isn’t very much like anything that Alexander suggested, and that in fact what Alexander did suggest is more interesting and would probably be more useful for programmers than what the design patterns movement chose to take.
One of the things I pointed out was essentially what Norvig does: that many patterns aren’t really addressing recurring design problems in object-oriented programs; they are actually addressing deficiencies in object-oriented programming languages, and that in better languages, these problems simply don’t come up, or are solved so trivially and so easily that the solution doesn’t require a”pattern”. In assembly language,”subroutine call” may be a pattern; in C, the solution is to write result = function(args…), which is too simple to qualify as a pattern. In a language like Lisp or Haskell or even Perl, with a good list type and powerful primitives for operating on list values, the Iterator pattern is to a great degree obviated or rendered invisible. Henry G. Baker took up this same point in his paper “Iterators: Signs of Weakness in Object-Oriented Languages”.
I received many messages about this, and curiously, some made the same point in the same way: they said that although I was right about Iterator, it was a poor example because it was a very simple pattern, but that it was impossible to imagine a more complex pattern like Model-View-Controller being absorbed and made invisible in this way.
This remark is striking for several reasons. It is an example of what is perhaps the most common philosophical fallacy: the writer cannot imagine something, so it must therefore be impossible. Well, perhaps it is impossible—or perhaps the writer just doesn’t have enough imagination. It is worth remembering that when Edgar Allan Poe was motivated to investigate and expose Johann Maelzel’s fraudulent chess-playing automaton, it was because he “knew” it had to be fraudulent because it was inconceivable that a machine could actually exist that could play chess. Not merely impossible, but inconceivable! Poe was mistaken, and the people who asserted that MVC could not be absorbed into a programming language were mistaken too. Since I gave my talk in 2002, several programming systems, such as Ruby on Rails and Subway have come forward that attempt to codify and integrate MVC in exactly the way that I suggested.
Progress in programming languages
Had the “Design Patterns” movement been popular in 1960, its goal would have been to train programmers to recognize situations in which the “subroutine” pattern was applicable, and to implement it habitually when necessary. While this would have been a great improvement over not using subroutines at all, it would have been vastly inferior to what really happened, which was that the “subroutine” pattern was codified and embedded into subsequent languages.
Identification of patterns is an important driver of progress in programming languages. As in all programming, the idea is to notice when the same solution is appearing repeatedly in different contexts and to understand the commonalities. This is admirable and valuable. The problem with the “Design Patterns” movement is the use to which the patterns are put afterward: programmers are trained to identify and apply the patterns when possible. Instead, the patterns should be used as signposts to the failures of the programming language. As in all programming, the identification of commonalities should be followed by an abstraction step in which the common parts are merged into a single solution.
Multiple implementations of the same idea are almost always a mistake in programming. The correct place to implement a common solution to a recurring design problem is in the programming language, if that is possible.
The stance of the “Design Patterns” movement seems to be that it is somehow inevitable that programmers will need to implement Visitors, Abstract Factories, Decorators, and Façades. But these are no more inevitable than the need to implement Subroutine Calls or Object-Oriented Classes in the source language. These patterns should be seen as defects or missing features in Java and C++. The best response to identification of these patterns is to ask what defects in those languages cause the patterns to be necessary, and how the languages might provide better support for solving these kinds of problems.
With Design Patterns as usually understood, you never stop thinking about the patterns after you find them. Every time you write a Subroutine Call, you must think about the way the registers are saved and the return value is communicated. Every time you build an Object-Oriented Class, you must think about the implementation of inheritance.
People say that it’s all right that Design Patterns teaches people to do this, because the world is full of programmers who are forced to use C++ and Java, and they need all the help they can get to work around the defects of those languages. If those people need help, that’s fine. The problem is with the philosophical stance of the movement. Helping hapless C++ and Java programmers is admirable, but it shouldn’t be the end goal. Instead of seeing the use of design patterns as valuable in itself, it should be widely recognized that each design pattern is an expression of the failure of the source language.
If the Design Patterns movement had been popular in the 1980’s, we wouldn’t even have C++ or Java; we would still be implementing Object-Oriented Classes in C with structs, and the argument would go that since programmers were forced to use C anyway, we should at least help them as much as possible. But the way to provide as much help as possible was not to train people to habitually implement Object-Oriented Classes when necessary; it was to develop languages like C++ and Java that had this pattern built in, so that programmers could concentrate on using OOP style instead of on implementing it.
Summary
Patterns are signs of weakness in programming languages.
When we identify and document one, that should not be the end of the story. Rather, we should have the long-term goal of trying to understand how to improve the language so that the pattern becomes invisible or unnecessary.
[ Thanks to Garrett Rooney for pointing out some minor errors that I have since corrected. - MJD ]
[ Addendum 20061003: There is a followup article to this one, replying to a response by Ralph Johnson, one of the authors of the “Design Patterns” book. This link URL is correct, but Johnson’s website will refuse it if you come from here. ]
[Other articles in category /prog] permanent link
https://blog.plover.com/prog/design-patterns.html