Why we need to wrap.

What the approaches to wrapping are.

When, and when not, to use the following wrapping technologies: C APIs, dynamic shared libraries, screen scraping, peer-to-peer, and the Common Object Request Broker Architecture (CORBA).

The trade-offs of wrapping.

Information technology shops of today have a huge investment in information technology; unfortunately, the vast majority of it isn't object oriented (OO). In the 1980's it is estimated that over $ 1 trillion was invested in information technology in the United States alone. Needless to say organizations are motivated to retain as much of this investment as possible. Wrapping is a technique in which you make non-OO technology appear to be OO by putting a layer of OO code around it, which is often a critical part of any significant OO project.

Oooooh, my first process pattern. All of the patterns I had written to date talked about programming things. This column introduced the first pattern that talks explicitly about people activities.

Jim Coplien was one of the first people to start writing lots of good patterns. Even though he is a good programmer, he chose to write his patterns out of his experience analyzing software development organizations. I was skeptical at first—what do these patterns of how people behave have to do with programming? It was around the time of this article that I began to realize that his perspective was as important as mine. It doesn't matter how good a job you do if you're doing the wrong job.

To make up for all the icky squishy stuff, I made sure I included plenty of code in the column. As aggressive as I think I am, looking at these columns reminds me that I go in the water half a toe at a time.

After the brief pause in the previous column to discuss philosophy, this column descends again into the depths of techno-minutiae. At least I talked about why you'd want to use instance-specific behavior, and didn't just present it as:“Here's a cool thing you can do with Smalltalk.”

The pattern Scriptable Objects still looks pretty good to me. In fact, I like it better as a pattern than many of the patterns that follow.

This was a very important article for me. I had been writing solo for some time. I needed to collaborate more, especially since I had been independent for almost a year and I was getting lonely for technical collaboration.

Bruce Anderson organized this fantastic workshop for IBM at its educational site in Thornwood, New York. Ralph Johnson was another one of the teachers. Late one night, I grabbed him and said, “I bet we can describe HotDraw using patterns.” He didn't know quite what I meant, but he has learned to humor me (probably because he's big enough to just bop me if I get out hand). There in a spartan little room in IBM's training facility in up state New York, we tried to recreate HotDraw using only patterns—this pattern tells us to create this object, then this pattern splits it in two, then…

The result was one of those crackling moments when you know you have something. Early the next morning, I described HotDraw to Desmond D'Souza, first using CRC cards the way I always had, then using the patterns. He confirmed that the pattern description communicated the “why” of the design much more clearly.

Ralph and I were confident enough of our findings that we wrote up the paper with a sweeping conclusion—any object architecture can be derived by applying a set of patterns.

You can't write a review without breaking some eggs. That was my conclusion after writing this article. I pretty much trashed the Enfin product as it stood, backed by my review research and a nasty experience at a potentially big client.

I was worried what my friends at Enfin would say after this came out. I was pleasantly surprised to find them supportive— “We know we have these problems. Let us show you how we are addressing them.”

I learned that readers appreciate it when you speak your mind plainly, but you'd better have some numbers to back up your opinions.

This was about where I started losing interest in writing the column. I had written this nice bit of code for a client, and I ran into a publishing deadline, so I turned it into a literate program and sent it off.

You'll notice that there are eight more columns after this one. Once again, my reluctance to change shows through. My lesson: once you decide not to do something, do not pass go, do not collect $200 (yep, that's the going rate). Quit and get on with something else.

In my case, I was distracted by trying to keep my business going (which in itself was too big a job for one person) and trying to get my patterns book done.

Not that this is a terrible column, or that it gives bad advice. The technique is useful, and belongs in every wizard's black bag. When I don't feel like writing the column, though, I shouldn't write the column.

This column takes a little bit bigger chance. I never worked out the instance variable taxonomy to the degree I did with temps, but I went ahead and published what I had anyway (as a column, it's not in the book), because I thought it was interesting and potentially useful. Looking at it now, I can't see how terribly useful it is. Sigh. Anyway, I was about to quit as columnist, and this and the previous column were just about rock bottom.

There are two notable points to make about this paper. First, it is one of the first times Ward and I published any pattern-related material (we presented some stuff at OOPSLA 87 in Orlando, I in Norm Kerth's “Where Do Objects Come From” workshop, Ward on a panel). Second, it argues that the worst problem of reuse is one of communication, not technology or economics.

The paper started out life as a Tektronix technical report. Ward and I had the habit of writing up just about everything we did as a TR. After we had written this, I think we submitted it as a position paper for some conference or workshop. Somehow, JOOP got hold of a copy and contacted us about publishing it.

The paper can be summed up as: “We created two sets of abstractions. The first was communicated as literate source code. The second was communicated as patterns for its reuse. The first set of objects was misused; the second was used correctly. We conclude that the problem of reuse is one of effectively communicating the intent of the code.”

This column is really just an application of Composed Method to deal with inheritance. Now I always try to make my code fragments be real code, no As, Bs, and Cs. You can see why from the example here that is written the other way.

The column is interesting in that it contains some of the first explicit links between patterns. Down at the end it says, “Use Composed Method if necessary to set this pattern up.” I paid considerably more attention to pattern linking when I wrote the pattern book, and I'll probably pay a lot more attention with my next set of patterns.

Patterns in isolation are all very interesting, but it is when they are linked together that they become powerful. It is only then that you can explain a simple solution to a problem, because you know that the rest of the solution was handled by previous patterns or will be handled by future patterns.

As if one crusade wasn't enough, I had to take on the sacred cow of inheritance as well. This must have been my “caped crusader” phase. I still think inheritance is overrated, but I don't generally get in anyone's face about it anymore. Too many windmills under the bridge, I guess. There I go, sounding old and worn out again.

I like the way the pattern form makes concrete and clear the technique of separating state-related and service-related code. The how of it is clear, as is the why.

This is one of many attempts I have made to explain the pattern I now call Composed Method. I must have written this pattern six or eight times. Persistence (my wife calls it “stubbornness” for some reason) can make up for lack of raw talent.

The two patterns here are written as transformations and named as a transformation—you have a method and you split it apart or you have a class and you split it apart. I was very big on “patterns as transformations” for a while. All the patterns in the pattern book are written differently—as descriptions of the things created, not the process of creating them.

This column is the site of my greatest disaster as a column writer—I promised something I didn't deliver. This was another one of those “write the first half now and the rest later” columns. Unlike the column about applying patterns to design, however, I didn't know the second half of the material when I started. I stil feel bad about this, but I still don't know the material for the second half, so I still can't write it

I really like this column as a piece of pedagogy. It is an excellent example of lie management. I describe garbage collection simply one way, then simply another, then combine the two for a truer picture of garbage collection. And hey, I even included a bunch of pictures.