Are there any patterns in GoF? [closed]

Question

I'm currently learning for a Design Patterns exam (which will take place tomorrow...). In one of the "test exams" I found the following question:

Jim Coplien said during the invited lecture that there is not even one design pattern in the GoF book. What is your opinion about this?

Because I wasn't in this particular lecture (it was last semester ;) I have no clue what he could have meant. And I have no evidence that Jim Coplien said it, but I think that doesn't matter.

What do you think could he meant with this statement?

(I'm not sure if the question is appropriate for this forum, however, I wanted to ask.)

Answer 1

Patterns: The Notion is Grounded in Alexander's Work

The GoF claims to take its pattern inspiration from Christopher Alexander (as they say in the front matter of the book), who popularized the term in the broader field of design. To Alexander a pattern: is always an element of pattern language; contributes to deep human feeling; and is always geometric in nature. At least some of the GoF patterns fail on at least one of these points, and several fail on all three. Although "pattern" is a neutral English language word, the cultural and historic roots of the GoF work, combined with their invocation of Alexandrian inspiration, leave it subject to judgment by the fundamental criteria of its ancestor, and it comes up lacking. Even though they know, and express that they know, that they diverge some from Alexander, they still choose to use a term that he crafted, researched, and popularized, and I hold them accountable for that. (That said, they are all valued acquaintances; I was close to John Vlissides, whom we lost several years ago, and have had great dialog with Richard Helm and Eric Gamma on the deeper issues behind this. My discussions with Ralph have been less interesting as they stop at the engineering level.)

Historical Roots

Words mean things. The Alexandrian sense of the term "pattern" was not well understood by the GoF (or by the software community as a whole) when they wrote the book, but they built on the vulgar perception of the time, which was grounded in three sources: 1. Erich Gamma's Ph.D thesis; 2. Ralph Johnson's framework work, and 3. the C++ idioms book (you can find this in the GoF book's own explanation of its sources in section 6.3). (Oh, Knuth was also an influence.) I continued to challenge the authors about it but people liked it, and they liked that people liked it, so the momentum continued.

Several years later (2 December 2004) one of the GoF would write to me to describe his "aha" experience of finally understanding what Alexander was trying to convey. It was quite a bit different than what underlies the content of the GoF book:

Finally grok'ed "generative patterns" and piecemeal growth through a long tortuous route.... Largely through some interesting universal properties of software (scale-free and small-worldness)

A bit slow I am sometimes... but got there in the end...

GoF Patterns Address a Problem of Accidental, rather than Essential, Complexity

That people find them useful as they do is, unfortunately, an indictment of modern programming languages. The languages don't have the proper constructs to express the broken symmetry that Alexander holds to be characteristic of patterns, and which are intrinsic to complex design (Nature of Order, p. 187: "...in general, a large symmetry of the simplified neoclassicist type rarely contributes to the life of a thing, because in any complex whole in the world, there are nearly always complex, asymmetrical forces at work—matters of location, and context, and function—which require that symmetry be broken"; op cit., pp. 63-4: "Nature, too, creates beautiful structures which are governed by repeated application of structure-preserving transformations. In this connection, I think it is useful to remark that what I call structure-preserving transformations are very closely related to what has become known as “symmetry breaking” in physics."). Java in particularly bad about this but so is its ancestor Smalltalk. C++ is rich in features to describe local symmetry-breaking but most people don't really know how to use them. Richard Gabriel – who has also worked closely with Alexander, and who has languages like CLOS and Scheme to his credit — says that he simply doesn't understand the GoF patterns because a properly designed language (like CLOS or Scheme) doesn't need them. I am largely in that same camp.

The Design Movement

There's a lot of design theory behind this that goes back to the Design Movement (Thackara ("Design after Modernism", 1989), Naur, Alexander, Cross ("Developments in Design Methodology," 1984) and other authors in the 1980s). It has always amazed me how little programmers know of this body of literature and how wrong-headed much CS thinking is in light of the obvious findings of the work of the Design Movement at this time. Those of us who founded the pattern discipline (the original 7 of The Hillside Group) back in 1993 were familiar with the major themes of this literature. The PLoP conferences evolved a body of literature that devolved radically from these foundations, being more focused on arcane knowledge than the "quality without a name" that Alexander sought.

Origins of Idioms

The reason I introduced idioms for C++ programmers was to allow them to do object-oriented programming when the language got in their way. Now, we have more powerful approaches like DCI that greatly reduce the need for idioms. Patterns still apply at the domain level — which is in line with Alexander's vision. There have been a few good pattern languages written; e.g., by Hanmer (Patterns for Fault-Tolerant Software, 2007); by Eloranta et al. (Designing Distributed Control Systems, 2014), and the Organisational Patterns which Alexander himself noted met the necessary criteria (Coplien and Harrison, 2004).

The Battle Lost, but the Work Continues

Alexander and I (and Richard Gabriel — read his "Patterns of Software" — and others as well) share disappointment in this early redirection of a term that had been well-established in design before being re-defined by GoF. Yes because they call them Design Patterns, they are Design Patterns — in the context of any discussion about the Design Patterns book by the Gang of Four. In the broader scheme of design theory and architecture, they are not: they are only idioms. Even as the authors themselves say, that's how they started out.

There are several efforts afoot to restore Alexander's vision to the software community. The ScrumPLoP® community (http://scrumplop.org) takes all the Alexandrian groundings of patterns very seriously. An old-time Alexandrian colleague, Greg Bryant, who used to do the IT stuff for CES, has reached out to me and told me of his work to get Alexander's vision back into software, and we're about to trade notes. I'm sure that Dick Gabriel always has something in mind as well though he and I haven't chatted for a while. In the mean time I continue to work directly with Alexander's colleague, Hiroshi Nakano, who connects Alexander's ideas (which he expressed directly in terms of the Tao te Ching in Timeless) directly into their parallels in Japanese culture. It's a much better fit than to try to shoehorn it into Western culture. That probably explains some of the frustration in being able to understand my claim — though it's not an excuse for a professional working in the knowledge business.

An Exhoratation to the Grumblers

Of course, all of this grounding is a matter of published dialectic and research and is available to anyone willing to take the time to research it. It is not as casual a matter as can be quickly dismissed as it was here. It took me 20 years — and I had direct access to the sources. I can appreciate that it's difficult for the average programmer to dig into these things, but I would suggest doing a bit more research before dismissing a well-researched position out-of-hand, before doing one's homework. It's a StackOverflow thing.

Answer 2

By the GoF's own definition, it's full of design patterns. So by inference, Coplien has a different definition of a design pattern, or Coplien has misunderstood or misreptresents GoF's definition, or he argues that the GoF definition does not match the GoF patterns.

The question invites you to describe the differences between the two definitions, and provide your opinion on which definition you prefer. Probably your REASONED opinion, as in academia your reasons for your opinion (methodology) matter a lot more than the the opinions themselves.