Design Patterns Book

Design Patterns: Elements of Reusable Object-Oriented Software by ErichGamma, RichardHelm, RalphJohnson, and JohnVlissides (the GangOfFour)
ISBN 978-0201633610 , ISBN 0-201-63361-2
Publisher: AddisonWesley Professional (November 10, 1994)
ProgrammingBookAcronym: GoF

ISBN 0-201-63361-2 One of the first, and most well-received books on DesignPatterns.

You can find more on the GangOfFour DesignPatterns at:

FIXME - these links are down! Original location: http://wiki.cs.uiuc.edu/patternStories/[patternName] e.g. http://wiki.cs.uiuc.edu/patternStories/AbstractFactoryPattern

Creational (CategoryCreationalPatterns)

Structural (CategoryStructuralPatterns)

Behavioral (CategoryBehavioralPatterns)

Criticism

Failed to provide clear criteria for when to use what pattern, and explain the criteria for the rules or choices (such as cost/benefit analysis of find & change costs or something from CategoryMetrics).
Focused mostly on SystemsSoftware, mostly ignoring database and CrudScreen-centric applications.

These are questionable criticisms.

First, patterns are not interchangeable, let alone on an economic basis, so "criteria for the rules or choices ... such as cost/benefit analysis" do not apply. The intent, motivation and applicability portions of a pattern description are sufficient to compel and/or inform use of a particular pattern. Using economics to decide whether to use Visitor or Singleton is akin to using economics to decide whether your new house should have a roof or a door.

TuringEquivalency ensures that there are plenty of different ways to do the same thing. And please elaborate on your economic complaint. Your roof/door analogy escapes me.
OO design patterns have nothing to do with TuringEquivalency. OO design patterns are not interchangeable. You don't decide Visitor vs Singleton on an economic basis, you decide Visitor vs Singleton because the coding requirements dictate Visitor or Singleton. Likewise, you don't decide whether to use a door or a roof on an economic basis, you use a door because you need to get in and use a roof because you need to keep the rain out.
I suppose if the premise is that one is ONLY going to use OOP, that could in part be true, but there is potential overlap even within OOP (although it probably hinges on how one defines OO.) Note that in small houses, doors can serve both purposes.
It is a book of OO design patterns, so the premise is that one is only going to use OOP to implement the patterns. Your door analogy is just quibbling.
If true, that's makes it very limited for multi-paradigm design guidance.
It's not intended for multi-paradigm design guidance. Note that the subtitle is "Elements of Reusable Object-Oriented Software".

Second, the DesignPatternsBook is specifically about object-oriented systems and general-purpose programming. Database and CrudScreen-centric applications almost certainly need their own PatternLanguage. Perhaps you could write it?

I do not believe it explicitly limits its domain scope.

It implicitly limits its design scope. You use a general-purpose OO language to build a DBMS, not as a DBMS.

Sorry, you lost me. There is usually at least a fair amount of imperative coding in most CRUD apps.

You complained that the book ignored database and CrudScreen-centric applications. Unless you're using an OODBMS -- for which the book and its patterns certainly apply -- you wouldn't use OO patterns to write SQL queries or paint screens and fill in event handlers. OO is used to build the tools that let you write SQL queries and paint screens and fill in event handlers.

Where in the book does it suggest not to use OOP to write the client-side of SQL-centric apps?

It doesn't, and for OO client-side, SQL-centric apps the OO design patterns most certainly do apply.

Then why not more examples from that domain? Why only include examples from SystemsSoftware? If you have 30 examples, it would make sense to distribute those examples among at least a half-dozen common domains rather than make all 30 in one domain. That's not rational unless being chinsy is your primary goal.

The examples are intended to be generically illustrative without being domain specific. I don't recall any games, graphics, or geographical computing, either.

Which is perhaps part of the weakness.

If the reader cannot apply generically illustrative examples to his or her specific domain, he or she has problems that neither this book nor any other can solve.

I'm guilty then. I couldn't do it. That's mostly moot anyhow, one ideally should choose a wide variety of domains for examples unless they explicit target a domain set (and should state so). I'm not burning the book, just knocking off some points for using narrow examples. No reason to get upset about that. You seem to be suggesting the reader should be expected to compensate for that gap by being smarter, but we are not rating readers here.

Choosing a wide variety of domains inevitably demands explanations about the domain that are otherwise irrelevant. Really, if you can't apply generic examples to your domain, that's a problem with you or your domain. Or both. Don't expect the authors of a book to fix that for you. Man up and fix it yourself.

It would not be much to briefly suggest and compare non-OOP alternatives or competitors to OO patterns.

{Then feel free to do so. But it's still outside the scope of the book in question.}

Indeed. I wonder if Top thinks the Haynes repair guide for his car should also briefly suggest and compare appliance repair, too.

The analogy would only work if your washing machine is used for human transportation. Different paradigms are used mostly for the same purpose.

So should the Haynes repair guide for your Chevy Vega briefly suggest and compare motorcycle repair? They're both used for human transportation.

If motorcycles were common enough, perhaps, yes, because it would be a common point of reference such that existing knowledge can be leveraged. For example, "Concept X is perhaps better illustrated in the well-known Motorcycle brand X's fluxpacitor (figure 7) because the design makes the foo and bar chambers stand out more and their connections clearer." In practice, motorcycles are too rare such that it's probably a bad idea. -t
{There are about ten million registered motorcycles in the United States. How common would they need to be?}
When I'm on the road, only about 1 out of every 100 vehicles is a motorcycle. Maybe it's different in other regions?
{Maybe. So how common would they need to be?}
As a rough rule of thumb, at least 20% or 30% of readers should be familiar with it to deserve mention, unless the evidence/point is self-standing such that obscurity doesn't matter.
By that metric, the GangOfFour book doesn't need to include reference to database and CrudScreen-oriented applications.
...Continued at CrudIsForBeginners...