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.

What metrics are and why they're important for object-oriented (OO) development.

Which metrics work for OO and which ones don't.

What metrics to use for estimating projects, improving your development efforts, selecting the right tools, and improving your development process.

How to use metrics effectively on your OO development projects.

Project managers are constantly inundated with questions about the status of their project. How good is our design? Can we start coding now? How long will the project take? How big is the project? How much will it cost? How many people do we need? Questions that are difficult, if not impossible, to answer with any certainty without taking measurements of specific factors that address these issues. But what should you measure? A good question.

I was really stuck trying to write the second half of the garbage collection column. By this time, I felt like I had the column thing wired- sit down, bang out, email. Ka-ching. Not this time. Nothing I tried worked. The column started out late. It kept getting later.

My solution, as you can see, was to rework material from my by-now-jelling patterns book. I didn't feel particularly good about it, because I knew it wouldn't change anyone's life dramatically, and I always wanted to have an impact. However, it got the column done.

I was kind of running out of gas for the column by this time. “Objects from the Interface” is a five-paragraph description of a topic that really deserves a book, namely how to factor user interface code. However, I really wanted to present “Objects from the User's World,” and I had to pair it with something to make it long enough.

I always worry when I'm writing if what I'm doing will be long enough. Long after it was clear that the patterns book was way, way too big, I was worried if I could produce enough pages. I think this comes from early writing experiences where I had minimum word counts. I got an “F” on a paper in fourth grade for submitting a 50-word paper, 43 words of which were “very.” That should have told me something about me and about the schooling system I was experiencing.

I got my name on this paper kind of by accident. I was a late arrival on the Vivarium project. Jay Fenton had been doing some very interesting work on programming languages for kids. He wanted to write something up for OOPSLA. I offered to help him.

I ended up reorganizing the paper enough that he offered to put my name on as an author. I felt a little funny, especially since the paper had been accepted with only Jay's name and I was the program chair and besides, I already had another paper in the conference, but I accepted anyway.

The next year, I was on the ECOOP program committee. We had our meeting in Paris. I remember eating lunch in the Xerox cafeteria. Next to me sat a bright, eager Ph.D. student. He began grilling me about the paper and the research behind it. Turns out his class had been given the assignment of figuring out how they would extend existing research, and the Playground paper was one of the three they could pick to extend. This was a shock, because I don't consider myself a scholar. Really I'm more of a talkative engineer. However, it was fun to be noticed.

Technically, I'm amazed at the prescience of Playground. Alan Kay was absolutely convinced that direct control structures, like Smalltalk's message send, would run out of gas and that “pulling” -style would come into vogue (even though the Internet apps call it “pushing”).

Why we need a class-type architecture, and more to the point, why we need a five-layer class-type architecture.

The implications of the architecture for both system development and for project management.

What each layer is really all about and how it fits in with the other layers.

Users want systems that are better, faster, and cheaper. Not only do they want new systems that conform to these requirements, they also want systems that are adaptable and modifiable. You might get lucky and get new requirements that are easy to meet, but I wouldn't want to count on it. Without a well-thought-out architecture in place you will probably not be able to develop applications in a timely and efficient manner that meet the demands of your users.

The class-type architecture presented in this chapter meets these goals.

This article gives the longer version of the story I told above in introducing the original CRC article. I was glad Marie Lenzi gave me the chance to write it, because I was able to make an explicit public statement that Ward invented CRC, even though my name came first on the original article.

This is clearly recycled material from the patterns book. Not much more to say here.

Why we need each type of diagram.

How to draw each type of diagram.

How to read class diagrams drawn in other modeling notations.

How and when to use use-case diagrams, sequence diagrams, state diagrams, process models, data models, collaboration diagrams, and interface-flow diagrams.

This book is an extension of The Object Primer and in this chapter we'll extend our knowledge of object-oriented analysis-and-design techniques. This chapter is perfect for people who wish to gain a broad understanding of the analysis-and-design options that are open to them when developing a system.