Here is a great example of a column I wish I'd never written. It presents a new control structure to deal with the complexity of the Composite/Wrapper pattern used in the user interface code in Visual Works. I wrote the column, sent it off, then had a quick talk with David Liebs about the subject. “So you need to talk to a particular wrapper, eh? Why don't you keep a pointer to the wrapper you need to talk to and give it a useful name? Then you can just send it messages.” Duh…

The other aspect of the column I regret is that it seems to condone adding new control structures to Smalltalk. The meta facilities of Smalltalk are extremely powerful, but 99.99 percent of the time, you shouldn't use them. Oh, they'd get the job done alright, but at what cost?

When you write something like #wrapperSend:, you have to take off your application-programmer hat and put on your language-designer hat. The responsibilities of the language designer are ten times as great as those of an application developer. Whatever you do, you have to implement it and test it, sure, but you also have to document it like a new language feature, extend the programming environment to handle it smoothly, and worst of all, maintain it through all future releases of the image.

Okay, back to tilting at windmills. Sometimes I think people just don't get Smalltalk. Why in the world would you want a grungy old explicit case statement when you have a superior substitute in the polymorphic message? How could you read and write Smalltalk code for enough years to be able to implement new language features and not understand that you didn't need them?

I guess my tights and cape aren't far enough at the back of the closet…

As with the previous column, this column has a strong confessional flavor. I like using my mistakes for columns, because I'm sure there is something to learn there.

The meat of the column is good stuff—refactoring and adding stuff becomes easy. I can't imagine how many times and ways I have said this in the last ten years. This is one of my better attempts, because it doesn't just say it, it shows it. (See “Make it Run, Make it Right” for another example.)

When I started writing this, I felt like I was getting preachy. Maybe that's what's so good about demonstrating from my mistakes—I can't be preaching if I'm explaining how I screwed up.

The personal material up front shows that I was aware that my attention was wandering. I'm glad I kept it together enough to say something important here.

This is my abortive attempt to bring patterns to the masses. Dr. Dobbs (which I used to read as a Silicon Valley brat in the late '70s) called to ask for a pattern article. I thought, “Here is my chance to step outside the narrow confines of the object universe.”

Ha. Nobody got it. I'm sure I misjudged my audience, but I think there are more serious problems with the presentation here. Looking at the paper again, though, I'll be hanged if I can figure what. I'll take a shot at it, though.

One of the problems is certainly that I am talking about a different kind of pattern here than most people talk about. The patterns in the Design Patterns book, for example, show you how people use objects over and over. You can take the same approach to using a particular framework, however. People use MVC the same way over and over. You can write the things they do as patterns.

Part of the problem with the paper now that I look at it is that I got away from Ward's question, “What is the one thing you want the reader to take away?” This paper is all over the place. Another problem is that the paper isn't explicit about even those points that it does make. It tells a story (kinda), but it doesn't come out and say, “Communication is the problem.”

What features to look for in an object-oriented (OO) language.

We'll compare and contrast the leading OO development languages: C++, Smalltalk, Java, and ObjectCOBOL.

How to develop for the world of electronic commerce.

What other development tools you may need to successfully build OO applications.

In this chapter we will discuss what features to look for in an OO language, describing the main features of each of the leaders. We will also compare and contrast the languages as well as discuss how to build electronic commerce applications using OO development languages.

This was my last column, and the one I'm proudest of. I have a habit of trying to take lessons from the world around me. If I see a tree leaning against another tree I say, “What is that like? Well, if one person leans on another too long, they both end up falling down.” I always kept these little stories to myself, though.

For my last column, I decided to break out. By now I was fully confident in my ability to describe a technical situation. I'd never tried to describe something from the real world in a publication before. This was my first attempt.

Looking at it now, it looks clumsy, but I still really like the underlying story. I've probably told the parable of the woodpile twenty times in the year since I wrote it.

In a way, this column represents the shift that I had been undergoing all along. I got completely away from technical stuff and completely into people stuff, and I did it in people-y, proto-literate way.

The various trends and techniques in creating distributed applications.

How to distribute applications using client/server technology, taking both a two-tier and three-tier approach.

How to distribute the classes of your object-oriented application using traditional client/server approaches, object-oriented client/server (OOCS), and applets.

How to create applications using Common Object Request Broker Architecture (CORBA), a distributed object standard.

The architecture for application development is becoming more and more distributed. We're moving from the centralized mainframe approach popularized in the 1960s and 1970s through the client/server approach of the 1980s, into the distributed classes and distributed objects approaches of the 1990s. In this chapter we will compare and contrast these approaches, concentrating on object-oriented client/server design, a technique for distributing classes across a network of computers.

Why your persistence strategy is important for successful application development.

What terminology is commonly used with respect to persistence.

How to map objects to flat files.

How to map objects to relational databases, concentrating on several critical topics: the impedance mismatch; mapping objects to tables; implementing object relationships; inheritance mapping strategies; and mapping success factors.

How to use object-oriented databases and object/relational databases as your persistence mechanism.

Persistence deals with the issue of how one ensures that the objects that he or she works with last, or persist, between invocations of object-oriented applications. In other words, persistence addresses one's strategy for saving objects to permanent storage. There are four common mechanisms used to store objects: flat files, relational databases, object-oriented databases, and object/relational databases. Although you may have heard that mapping objects into a relational database is a nightmare, and it can be if you make a mistake, we'll see in this chapter that using relational databases to store your objects is a very viable approach to persistence.

This was the column that generated the most interest and email for me, all of it positive. Other than that, there's not much to say, except “Get to work writing tests—yeah, you, the Smalltalk hacker.”

Notice that I am still calling what I am doing “idioms.” What I am describing are really patterns, even if they are small-scale patterns. I figured it was better to bring my audience along a bit, prove myself useful, and then spring the bigger idea of which this is all a part.

I wouldn't do this again. Better to just say what you mean, and if you lose some people, so be it. I have a real tendency to try to please everybody, so this approach kind of goes against the grain.

The tension between evolutionary and revolutionary change is something I struggle with constantly. On consulting gigs, it is always a temptation to just say, “Throw the bastards out,” to start fresh. Often this will produce the best results the quickest. However, it requires courage and a lack of ego to “toss out” hard work. On the other hand, I'm always worried that if I were a little smarter, I'd be able to deal with the situation as it is.

The column is a good example of a technique I learned from Dave Thomas that he calls “lie management.” You present an over-simplified but essentially correct view of the world, then you fix it. The engineer in me recoils at this—I will go to ridiculous lengths to understand things completely, and everyone must be like me, right?

This one seems like a real stretch now. Half the column is taken up describing a client and giving advice to other consultants. That's not what a Smalltalk I dioms column should be about, and it doesn't really fit. Not that the advice is bad; it just doesn't go with the rest of anything else I was saying.

The technical part still seems right on. I recently used MetaObject to extend tools for use with Gemstone, and it worked like a charm.

The other thing going on here was my shock at seeing myself quoted at length in an earlier Smalltalk Report. When I spoke at the first Smalltalk Solutions, I got pretty outrageous—taking digs at my friends and potshots at big companies. All this was dutifully reported, and it looked pretty stupid in print. I was both disappointed at myself for having said it, and disappointed that it was made so public. Well, so much more public.

The lesson for me out of all this is that if people are going to take what I say seriously, I'd better damn well take what I say seriously, too. That's tough to do without taking myself seriously, which would be fatal. Having four kids is a great antidote to ever feeling like you have everything under control, though, so I'm not too terribly worried.

Why we need to test our applications.

Which traditional testing concepts still work for object-oriented (OO) development and which don't.

How to test during all phases of the development life cycle: analysis, design, construction.

How to implement test cases within program code.

How to perform function, regression, stress, and user-acceptance testing.

Testing an object-oriented (OO) application is both very similar and very different as compared to testing a procedural application. The good news, if you can call it that, is that you still need to formulate test cases, you still need to document them, you still need to run and verify them, you still need both black-and-white box tests, you still need regression testing, and you still need stress testing. The bad news, however, is that the new development concepts provided by the OO paradigm require new approaches to testing. In this chapter we will discover several key concepts required for testing object-oriented applications.