What We'll Learn in This Chapter

One of the reasons, very often the main reason, that firms move into object orientation is that they want to improve the quality of the applications that they develop. They want systems that are easier to maintain. They want systems that are easier to extend. They want to develop systems better, faster, and cheaper. The question is “How do you know that you've succeeded?” In this chapter we'll see that metrics are used to answer this question.

There are a lot of object-oriented (OO) development environments and techniques available to you. Although this sounds good, the problem is that it isn't always clear which ones are the best ones for you.

While a program expresses intent, it is the computer, the hardware, that brings that intent to life. In order to have full control over your program's expression you must control the computer that runs it. Therefore, write your program for a computer with a plug. Should you be dissatisfied with the behavior of the computer, unplug it.

I'm working from memory here. This idea, the idea that you could unplug a computer, is an idea that has run in and out of our culture for about as long as there have been computers. I've expressed the idea as a pattern: a problem and its solution. I'm thinking about this pattern because it reminds me of programming with Kent.

I haven't got the words to this pattern quite right. It gives the impression that I fear computers run amuck. Does anybody remember that old film, The Forbin Project, where the U.S. defense computer gets to talking to the Soviet defense computer and they get the idea that they can run the world better than us? Well, that's not the problem. I first wrote the “don't program a computer you can't unplug” pattern because Kent and I needed a pattern at a large scale. We were looking for big advice for a new kind of developer. We imagined ordinary people taking their computing needs into their own hands. These people would use powerful languages to express themselves.

I'll tell you what happened to garbage collection. I sat down three times to write the next column about garbage collection, and nothing came out. Between that, my wife's ten-game winning streak at Cribbage, and 46 inches of rain so far this year (and it's still January), I'm pretty frustrated.

I've been reading Edward DeBono's book Thinking Course (highly recommended). One of the techniques he suggests, and also one I've seen in art, is when you're stuck, do the opposite. In art, if you're having trouble drawing a thing, try to draw something that is completely the opposite. Of course, it's impossible to draw “not a flower,” so you end up with something which gets at “flowerness” backwards. I'm writing a column about “not garbage collection.” I'm not sure where I'll end up, but at least the column will be done.

This is the fourth and final installment in my series on where objects come from. I deliberately started with the unusual and difficult ways of finding objects. There are lots of books that will tell you how easy it is to find objects. Just underline the nouns! The fatuous phrase that keeps popping up is, “…there for the picking.” Or maybe it's “plucking.” In any case, none of the objects you'll find with “Objects from States,” “Objects from Variables,” “Objects from Collections,” or “Objects from Methods” is there for the picking.

What We'll Learn in This Chapter

As an object-oriented developer you need to have an overall game plan as to how you intend to design your system. The class-type architecture described in this chapter provides you with an excellent strategy for organizing the classes of your application to increase both its extensibility and maintainability. I don't claim that this architecture is detailed enough for the needs of your organization. I do claim, however, that it does provide an approach to partitioning your applications that leads to a significantly better design.

This isn't another introduction to objects with CRC. It is a philosophical look back at CRC's place in the grand scheme of things. It presents what CRC is under the hood, where it came from, and what it is good for.

NOT A METHODOLOGY

What is an article on CRC doing in an issue on methodologies? CRC isn't a methodology. What? Your consultants told you otherwise? Well, as the narrator at the beginning of any number of Disney movies would say: I was there at the beginning, so let me tell you what really happened.

PERSPECTIVE

Before I get rolling, let me say that CRC was really Ward Cunningham's idea. As you'll see later in the article, his was the insight that really tied together several strands we had been pursuing together. You'll also see how I got my name first on the paper that introduced it to the public eye. Really, though—Ward did it, I helped. I hope that sets the record straight. Now, back to your regularly scheduled article.

The topic of this and the next column is how to use instance and temporary variables. I came upon the information (some of it is patterns, some isn't yet) in the course of writing my forthcoming book of Smalltalk coding patterns. I looked at temporary variables first, and found patterns for four ways temps are used:

1. Reuse the value of a side-effecting expression (like ∧SStream≫next∧T).

2. Cache the value of an expensive expression.

3. Explain the meaning of a complex expression.

4. Collect the results of several expressions.

Success in hand, I went to look for a similar set of canonical uses of instance variables. No dice. I came up with a taxonomy of the uses of instance variables, but no patterns. Many of the uses are bound up in other patterns (like the instance variable that holds the current State object). Others are too vague to make good patterns. I'll present what I have so far, because I have found it useful even in its unpolished state.

Ward Cunningham and I had a good long talk about this. We decided that the reason I was having so much trouble was scope. In the first book I am looking for coding patterns, the tactics of successful Smalltalk. Choosing to use a temporary variable is a tactical decision.

What We'll Learn in This Chapter

There's more to object-oriented (OO) development than CRC (Class Responsibility Collaborator) models, use cases, and class diagrams. Although all three techniques are useful, they don't give you the whole picture. In this chapter we'll see several types of diagrams that help to fill in the blanks: use-case diagrams, sequence diagrams, state diagrams, interface-flow diagrams, data models, collaboration diagrams, and process diagrams. We're also going to compare the Ambler notation with other leading notations to help you understand the class diagrams that you see in other OO development books.

The Importance of Bubbles and Lines

Management is constantly talking about deliverables. These are usually, but not always, physical by-products of your development effort. Although the ultimate deliverable should be a fully functioning application that has been successfully installed and accepted by the user, interim deliverables often include project plans, analysis documents, design documents, test plans, and so on.

This month's topic is case statements: practical necessity or pernicious contaminant? My interest in the topic comes from several areas at once. SmalltalkAgents has added a form of case statement to their Smalltalk for the Macintosh. CompuServe has hosted a lively discussion of isKindOf: and its relatives. Finally, net news has had a discussion of case statements. What's the deal?

Cutting right to the punch line, I think case statements are an inappropriate holdover from procedural thinking. While vital in procedural languages, their use in object programs is obviated by the much more powerful mechanism of the polymorphic message send. Anytime you find yourself wishing for or using a case statement, you have an opportunity to take advantage of objects instead. The noncase version will yield a more maintainable, more flexible, more readable, and faster solution.

Is it my imagination, or are these columns getting harder to write? I think I know exactly what I want to say, but I've started writing three different times without getting anywhere. Maybe this third time will work.

Simply put, here's what I want to say—the best programming style for Smalltalk is to have lots of little methods, and lots of little objects.

That's a pretty broad statement, broad enough that it can't possibly be true in all cases. What are the tradeoffs, the issues that affect programming style?