Concerning Design Patterns
A while back I got a copy of the gang of four design patterns book1, and although I started reading it only shortly thereafter, I only got around to finishing (indeed, to reading most of it) a couple of weeks ago. I mostly wanted to read it because I understand it to have been a rather influential book, although it appears that much of that influence came from a group of people deciding that its teachings were the single path of true enlightenment (with regard to software design, at any rate), and a reaction from another group who sought to dismiss it, based on the first group's over-zealousness.
It appears, naturally enough, that the middle ground is a more sensible place to be. The idea of design patterns does not utter reshape the way one approaches all software design, but neither is it a useless waste of time. Based on my own experiences, I think that the idea of design patterns is mostly useful because of the vocabulary that it provides (although this vocabulary is neither sufficient nor strictly necessary for good design). Unsurprisingly, this is one of the reasons the GoF present for the use of design patterns:
Design patterns provide a common vocabulary for designers to use to communicate, document, and explore design alternatives. Design patterns make a system seem less complex by letting you talk about it at a high level of abstraction than that of a design notation or programming language. (Gamma et al. 352)
To be specific, a few days after finishing the book, I realized that in writing a section of a program I had used what could be described as the GoF's Template Method pattern, although I had expressed it in a rather different way than what they suggest2. This was interesting, but didn't really matter much, this time at least, since I had already finished planning and writing the code in question before the idea struck me to describe it this way, but it caught my attention.
Yesterday, however, one of the undergrads working in our office asked me for advice on a design problem he had encountered, and I was not only able to quickly propose an idea based on one of the GoF's patterns3, but the vocabulary of the pattern made it quite easy to describe to him what I was talking about. I think that i would probably have arrived at the same idea otherwise, but the process would have been slower and both my thinking about it and my description of it would have been less clear.
The conclusion I've reached from this is that there seem to be definite situation in which the terminology of design patterns can be quite useful for streamlining thought, but that one should expect modest results; most of the time one will be concerned with relatively fine details of the project at hand that really don't need any such sophistication. The capacity for sophistication can be very nice when one does have a good opportunity to apply it.
-
That wikipedia article is, at the time of writing, actually kind of terrible, aside from its introductory section; over half of it is taken up by a blow-by-blow recounting of the book's first two chapters. ↩
-
Unless I forget, I'll write about this specifically later. ↩
-
In this case it was the Memento pattern; my colleague was doing a simulation in which he had an object which owned many sub-objects and needed to change its state by instructing the sub-object to change, but would potentially need to roll back that change after doing a test which required a large calculation to examine the resulting state of the whole. He was concerned that he would either have to store the entire state of the large object, or make the large object know a great deal about its sub-objects (and in fact their sub-objects). ↩