This is a bit of work I am particularly proud of. I wrote a little workspace that got me a method list browser on all the methods in the image that use “super” (that in itself was fun). Then I went through them trying to categorize each one. I felt like a real scientist there for a minute- taking samples, making hypotheses, testing them in the “real world.” The result is a “theory of super,” which is much simpler than the language feature (and perhaps not coincidentally quite similar to the “inner” feature of Simula, from which super was derived).

This is the biggie, the paper that made my name (and to a lesser extent Ward's, since he was already a little famous). I got my name first on the paper because of our rule that whoever wrote the first draft of a paper got to put his name first. This has caused considered confusion since then, with people crediting me as the inventor of CRC, or telling Ward how exciting it must have been for him to work with me.

There are a couple of stories about this paper. First, the title. Ward and I wanted to be very careful not to claim more for CRC than we could prove. We knew it was good for teaching “object-think,” so that's the approach we took in the paper, the one single point we pushed. We deliberately understated what we thought the impact would be, leaving it to our readers to extrapolate to making CRC cards into a design or analysis technique. We spent at least an hour on the phone polishing the title, and the result pleases me as much now as it did then.

Another story- I missed OOPSLA '89, waiting for the arrival of Lincoln Curtis, child number two. I had no idea of the impact of this paper. Then I attended OOPSLA '90 in Ottawa. I was in a “Design and Analysis” BOF. The biggies were all there: Booch, Constantine, Yourdon.

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.”

If you have read The Smalltalk Best Practice Patterns, you can see in this column the beginnings of the section in the book on collections. Once again, I mined the material from the image. Thinking back, I'm amazed at how important reading the image has been to me. I can remember being incredibly frustrated at having to spend all day looking for the method or class that I wanted, but then realizing at the end of the day that I had gotten more accomplished with six hours of reading and ten minutes of typing than I used to accomplish with ten hours of typing.

We may underestimate the value of a shared body of literature (the image) in creating and sustaining the Smalltalk culture. Perhaps that's why the visual “wire-and-fire” front-ends failed to have much impact-there was no corpus of visual code that everyone routinely consulted.

Object-oriented concepts, including a few that we missed in The Object Primer.

Modeling techniques like class responsibility collaborator (CRC) modeling, use-case scenario testing, and class diagramming.

An iterative development life cycle called “The Pinball System Development Life Cycle (SDLC).”

What this book is all about.

Unless you're reading The Object Primer and Building Object Applications That Work back to back you're going to need a quick refresher. Furthermore, there's some new material in this chapter starting in section 1.3 (hey, like we'd want you to skip an entire chapter).

Until the release of this book, The Object Primer was the greatest thing since time-sliced bread. Now we have Building Object Applications, a book that is even more spectacular than its predecessor. In The Object Primer we covered analysis techniques such as class responsibility collaborator (CRC) modeling and use-case scenario testing. We also introduced several object-oriented (OO) concepts and showed you how to model them using class diagrams. We finally put all this into the context of the Pinbail System Development Life cycle (SDLC), an iterative and incremental approach to OO systems development.

I wrote this paper in one sitting in my favorite coffee shop in Boulder Creek, perched out over the creek sipping a mocha (several mochas, in fact). I was trying to come up with a catchy intro. When the time machine idea came to me, the rest of the article wrote itself.

I don't know whether it will reproduce in the book, but in the magazine, the words “Star Trek” in the fourth paragraph were done in the Star Trek font. I was impressed that someone had the time and ingenuity to put in that little touch.

The other lesson in this is that the coffee shop in question closed soon after. The building owner wanted to jack the rent way up once the shop was successful, and the shopkeeper closed down rather than pay. The shop had become a gathering place for the community. Our little town still hasn't recovered

What I take from this is that even though as a businessman I have to pay attention to the bottom line, every decision I make also affects real people's lives. Once you're committed, not following through may have a huge cost for other people.

This was the first article I wrote after the big splash. I was asked to write the article for a special issue on objects, “something about CRC cards.” I remember re-reading the “Laboratory…” article and thinking, “I can't do anything better than that. That article says it all.”

After a brief pause for a personal crisis, I thought, “What the hell. I'll just write the same stuff with different words.” What came out, though, was very different. The original CRC article convinced bright people that CRC was a good idea. This one convinces regular engineers that they, too, can get started with objects.

Ward's goal when we wrote together was to write prose that fairly dripped with meaning. You could read the same sentence every six months and get new meaning out of it. The result is complex, dense, evocative, and sometimes hard to read.

This article is the first time I found my own voice. My writing voice is much plainer than Ward's. I write like I speak: plain and direct (although I generally use fewer expletives when I write). Both Ward's style and mine are directly at odds with my academic training, which was to layer any possible meaning behind layers of jargon, notation, and convoluted sentence structure. I suppose it's no wonder it took me a while to get over that.

What OO patterns, including both analysis patterns and design patterns, are.

How to use OO patterns effectively in the applications that you create.

How to create new OO patterns.

How to apply OO patterns throughout the life cycle.

What the advantages and disadvantages of OO patterns are.

Considering the number of combinations of operating systems, hardware platforms, and network protocols can you reasonably expect to be able to purchase business objects off the shelf? I'm not so sure. But what I do know is that developers are constantly solving the same problems over and over again. How many of you have been involved with developing inventory-control software? Or human-resource-management software? Or billing software? These problems keep repeating themselves over and over again. Although everyone's inventory-control system is different, the fact is that there is a lot of similarity between the designs of these systems. Wouldn't it be nice to be able to pick a design up off the shelf that has 80—90% of the thinking done for you already and all you have to do is develop the differences that are unique to your organization? That's what object-oriented (OO) patterns are all about, they're blueprints of generic designs that you can apply to the systems that you develop.

You may have noticed me putting more and more personal comments at the beginning of columns. I think this resulted from getting more and more comfortable with my role as a columnist (even as I was losing interest—I didn't say I was straightforward).

I beat on the “inheritance, feh” horse a bit more in this column, but as before, I try to explain what to do about it, rather than just bash.

The other thing I noticed while rereading this column is the extra pattern thrown in at the end. I didn't do it to pad. I did it because I was honestly embarrassed to have missed it at the client and I didn't want other people to make the same mistake. This violates the “what one thing do you want to say” rule, but it doesn't bother me here. I'm very clear that there are two things to talk about, from the title on down. The power of any rule is when you understand it well enough to break it.

Kent comes clean. I'd never tried to explain patterns in print before, not at any length. This was a bit of an experiment for me. Looking at it now I'm a bit disappointed, because the presentation violates one of my cardinal rules of teaching—always go from concrete to abstract. Were I writing this again, I would take some disguised pattern I had presented earlier and present it both in idiom format and pattern format. Oh well…

One thing I like about the column is the emphasis on communication. Looking at the earlier columns, I'm surprised at how little I said about the importance of communicating through code. I'm sure I understood how important communication is, but I hadn't written about it since the early HOOPLA! articles.

Why the right attitude is everything when coding object-oriented (OO) applications.

How to work with attributes effectively to make your applications easier to maintain and enhance.

How to develop high-quality methods and classes.

What tools you can use to enhance the development process.

How to organize your development efforts around the class-type architecture in an effective manner.

One of the most important lessons that you can learn about building applications is that there is more to it than coding. In this chapter we will discover a multitude of techniques that you can use to improve your application construction efforts. Everything covered in this chapter is applicable to any object-oriented (OO) language that you work in. This is important because it will help to give you skills that you can apply when you are working in any OO development environment, and not just in the one that you have today. The best skills are the ones that you can transfer to your next project.

How to overcome the object-oriented (OO) learning curve.

What we've learned in this book.

By reading this book you've made a really good start at overcoming the OO learning curve, but that's all you've done, made a really good start. There's still a lot of work ahead of you. More reading, courses, mentoring, and lots of development work. There is a light at the end of the OO tunnel, and this chapter tells you how to get there.