Initial thoughts on the GoF Documentation Model

February 22, 2010

The GoF book uses a consistent structure for documenting each of their services and as we have discussed repeatedly now on the applicability of their model to ours, I’ve taken a look at their structure and will outline my thoughts on each of their sections. I will list out the section and my thoughts on it’s applicability to our project:


A brief (1 sentence) description of what the pattern does. e.g. “Provide an interface for creating families of related or dependent objects without

specifying their concrete classes.” I like this as it’s quick, doesn’t require a lot of effort, let’s you quickly get an understanding of what it does and I think can be used in our model.

Also Known As

I don’t think we really need this.


This section speaks to why the pattern is useful and to what problem it solves, really why it exists in the first place. This is an excellent candidate for our services which may not be obvious for some of the less generic ones and gives excellent context to learning about what it actually does. It’s slightly longer than the others (2 – 3 paragraphs) which I think would be an appropriate goal length for ours as well.


The book uses this section to give a quick (bulleted) list of some situations when to use this pattern. Another excellent candidate for our services, a quick list to highlight some scenarios when you’d want to use a particular service.


A (graphical) representation of what the pattern looks like, UML diagrams. I don’t think this is overly helpful to our cause the “structure” of the service I don’t feel is particularly important to how it’s used or implemented. Really the implementation details will figure out the structure as need be but there is not necessarily a common one. A simple example is Loggers which can be implemented in and have drastically different structures depending on the targeted output.


This section of the book details the participants as show in the structure; if we don’t need a structure section we don’t need this either.


Who does what; again not needed for our format.


This section talks about the benefits and liabilities of using each pattern. I don’t have a definite answer but I don’t know that this would be that helpful for talking about the risks and rewards in using a specific service. There may not even be another way in some cases, which is where we differ in concept from the book in that they are taking a collection of practices that are a bit of the “wild west” in how they are done and attempting to pull out the good parts and standardize them into patterns whereas a lot of our services are simply THE way you do something.


This section is a little closer to the metal and gives hints and considerations when implementing the pattern. It will do things like highlight languages, language constructs or features etc. that suit a particular pattern well and provide some issues to think about in the implementation. Something akin to this would be useful as a brief section in the details on the producer of a service, some things to consider when implementing it that the developer may not have thought of otherwise.

Sample Code

Self explanatory and as previously discussed we are trying to avoid discussing the services at this level.

Known Issues

<insert any 1 of many jokes about the current state of the code/documentation here> This section talks about certain implementations of the services in different software packages and some known issues regarding them. Not applicable for us.

Related Patterns

Related services would certainly be applicable… “People using this service have also bought services X, Y and Z” a’la Amazon.

In summary, the sections I think we can borrow (copy) are:

  1. Intent
  2. Motivation
  3. Applicability
  4. Implementation
  5. Related Patterns (Services)

To give it the 5 W’s test, we have the Who and the When in Applicability, we have the  Why between Intent and Motivation. The What is sort of implied in Intent and Motivation but perhaps we should still include a description of exactly what the service is? The Where is missing completely, and we should include a Usage section perhaps on how to use it, not from a code level but more abstractly, like to say “query the context for it” etc. The Related Patterns (Services) section provides some good further information, but looking at some of the sections we skipped from the book, I would think it may also be useful to add a section called something like Tips or Extra Info to have a spot to put any other tidbits of information that would be useful. The book formalized them into their own sections because they had enough of it for each pattern, but in our case I think we may just have some tidbits here and there and it would be more consistent just to have a little section to put them in.

This post was just an initial flyby of the style used in the book, the real test on applicability will be trying to fill the sections we’ve thought of to see how it really fits. This is a perfect example of an article of clothing looking like it’ll fit in the store and being 3 sizes to small when you bring it home; you just don’t know until you try it on.


2 Responses to “Initial thoughts on the GoF Documentation Model”

  1. Christina Says:

    I really like this new blog format. It’s interesting to read and seems to capture your experiences better than the wiki. Also I appreciate reading the minutes of our meetings.

  2. […] One piece of documentation which has become a recurring topic of discussion at our team meetings is the much-lauded gang-of-four “Design Patterns” book.  It’s value in relation to our task has already been discussed by Brent here. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: