Noel Rappin Writes Here

Maybe more about the past than you needed to know?

Previously on Locally Sourced: I wrote about kinds of object-oriented design. Before that, I asked why you hired that test. I didn’t exactly set out to write 1300 words on the history of OO design, but I pulled out some old books and got nostalgic. Tune in next week for more on Agile, communication, and inclusion.

As I was writing the last post, I started skimming through a couple of my Object-Oriented textbooks from the mid-90s. I had forgotten some of the 90s OO hype. And I had really forgotten the OO literature I was reading then was different from what I encounter now.

In the mid-90s I was a grad student researching methods of teaching developers how to code. And at the time, the cutting edge meant teaching Object-Oriented programming (Sidebar: one clear research finding of the time was that it was easier to teach OO to a novice than to an intermediate who had already learned programming without OO. I wonder if that’s still true.) OO wasn’t new at the time (it dates back to the 60s), but it was having a moment with C++ getting more popular, and the release of Java (Java applets were going to take over the world…). OO programming was suddenly much more accessible to many more developers.

What I see in looking at the books on OO that I have from that time is an emphasis on pure domain modeling that I don’t see in the work I do these days.

Another Sidebar: There was one strong exception to the focus on domain modeling in the 90s: the original Gang of Four Design Patterns book, which came out in 1994. This book was ubiquitous in the field for over a decade, and was, to use my own taxonomy, very much a Technical Modeling book.

Anyway, I’m looking at a book called The CRC Card Book and I see right here in the first paragraph of the preface: “Object-Oriented projects follow a new software development life cycle, one that is both iterative and incremental, a cyclic spiral of analysis, design, and deployment.” (OO was going to change the world. Did I mention this book has a forward by Kent Beck? There’s a lot of overlap between this wave of object-oriented design and the first wave of XP/Agile.)

They go on: “In this new application-development process, determining and defining properly the classes that are central to the desired system at the beginning of the life cycle is critical. Thorough analysis of the problem and good design up from saves time, and money and helps ensure a successful end result”.

This preface raises a bunch of questions, not the least of which is “What’s a CRC Card?” Great question. CRC stands for Class, Responsibility, and Collaboration. It’s a brainstorming technique for system design, where each potential class in the system gets an index card with the class name, a list of its responsibilities, and a list of the classes it needs to collaborate to work with. Not only is there a whole book discussing how to use CRC cards, but I was (and am) very excited to own and read this book.

A very common theme of 90s flavor OO Design was the idea that this kind of object modeling was the bulk of the work in system architecture — getting the object model right was the hard part, the rest of the system was all downhill. The whole idea behind UML diagrams was that a formal system of creating and writing these models down would lead you to be able to automatically generate the bulk of a system. I have a book here somewhere that’s from a few years later, but which strongly suggests that eventually, all developers will have to do is put the requirements into a model and the entire program could be generated.

The other 90s book I was looking at was Object Models by Peter Coad. One of the first things it says about object design is “Look for objects that the system might know or do something about… actors…, places, things”.

In the 2010s, Sandy Metz says basically the same thing in POODR: “read through the description above looking for nouns that represent objects in the domain.” But that’s not the first thing she says. Before talking about nouns, she’s talking about cost of change. “Your goal is to model your application…such that it does what it supposed to do right now and is also easy to change later… A class should do the smallest possible useful thing; that is, it should have a single responsibility.”

The contrast here is mostly one of emphasis. The 1990 books talk about splitting out into nouns first and “seeing the world as objects”, and then only later getting into practical concerns like how to split off responsibility. 15 or so years later, Sandi starts with talking about cost of change and responsibilities, then allows as how looking for nouns is a good way to get started. (The CRC book does not have the concept of single responsibility for a class, as far as I can tell, but a CRC responsibility may also be smaller than a Sandi Metz responsibility. If that made any sense.)

POODR is much more amenable to practical refactorings that aren’t quite things in the real world, like NullObjects, when the CRC book talks about classes that aren’t nouns in the system they seem to be talking mostly about abstract parent classes. (Sorry if that sounds wishy-washy, I’m kind of skimming the CRC book).

This is all oversimplified, Peter Coad and Sandi Metz aren’t the only two people to ever write about OO design. But my recollection of the time is that the kinds of practical cost of change issues that Sandi writes about were just not an issue when I was teaching it in the 90s, the goal was to model the real world system and the pragmatics would take care of themselves.

I was big into a lot of this, at least the domain modeling part. The part about being able to generate running code from UML diagrams always seemed to be somewhat removed from how projects really work.

I taught undergrad OO design, and we very much taught this kind of domain process. Write down the requirement. Circle the nouns. Each object should be responsible for the things that is done to the real-world analogue of that object. I was so into it that I still own a copy of the CRC card book. I own a textbook on object modeling that is 500 pages long, contains no source code, and the author’s bio says that he has “built hundreds of object models”. And I thought it was great. Still kind of do, if I’m being honest.

And yet. I’ve been a professional developer of Object-Oriented languages for most of the past 20+ years. I never used a CRC card professionally. I can’t remember the last time I did a “circle the nouns” exercise. I stopped a team from doing UML diagrams (for very good reasons). In fact, I had sort of forgotten that this whole part of discipline existed.

What happened?

A few things, I think.

The UML bit was pure hype and it washed out pretty quickly.

Practical experience, I think, led developers to come up with more practical ways of handling OO designs. Just slightly after these books were written, you started to get the next wave of writing about OO design. There was a lot more technical design focus, which eventually coalesced, for better or for worse, into the SOLID principles.

But I also think that as OO languages became more ubiquitous, and especially with OO scripting languages like Python and Ruby, OO programming moved into areas that were maybe less amenable to this kind of real-world object modeling, and I think more to the point, OO programming was adopted by a set of programmers who either never learned or just didn’t want to do domain modeling.

And it turned out that OO without so much domain modeling worked out… fine. Or at least, fine enough, probably in a “worse is better” kind of way. Then Agile came along and changed how developers think about design.

Part of me thinks that this heavy domain modeling focus was really great, and we should do more of it. Part of me thinks it was impractical, or at least was not related to practical concerns. I’m glad we’ve come up with other object techniques. I don’t miss UML diagrams. But I do kind of miss CRC cards.