A Challenge for Modellers
Like many software developers of a certain age, I had a brief love affair with UML in the 1990s. Pictures of programs—what a great way to communicate! In my case, it lasted about four months. I simply didn’t find class diagrams helped me understand what was going on in my programs, or anyone else’s.
I think I can finally explain why. Over the weekend I started reading Olsen’s Design Patterns in Ruby, which is possibly the best introduction to design patterns I’ve ever read [1]. What I suddenly noticed, though, was how hard it would be to know which patterns the author was talking about if you blanked out the class names in the UML diagrams given with each chapter.
This is definitely not the case in other fields that rely on graphical notations. The logic gates making up a one-bit adder, for example, are unmistakable; the text around them speeds up understanding, but the meaning is in the diagram.
So here’s an empirical test: draw UML diagrams representing various design patterns, but don’t label them, and see how many people can tell which are which. Or analyze the natural language description of the design pattern and see how much of the information needed to understand how the pattern works is not present in the diagram. Yes, you can get some of that by adding a sequence diagram as well, but I’ll bet that even the combination still needs to be explained in order to be comprehended.
And while we’re on the subject: has anyone ever designed a programming language by starting with a catalog of design patterns and asking, “What do I need in order to make expressing these simple and obvious?” If so, I’d be grateful for a pointer…
[1] There are several reasons Olsen’s book is so good:
- He clearly likes the languages he’s using (English and Ruby), and knows how to use both well.
- The classic Gang of Four patterns are much simpler to express in dynamic languages like Ruby than in modern Java or C++.
- We’ve learned a lot since the original Gang of Four book about how to teach patterns and in what order.
#1 is the most important, though; I hope he writes a Python version soon.
Ok, this is one of those post that make you think “Hey, I’m not the only one”. I thought it was my fault. Will have a look at the book. It wouldn’t be the first time that a reading suggestion of yours works for me.
Your post made me think a bit. The schematic representation of logic gates is very nice, however logic gates are not really components, they are actually more like patterns. If you looked at the series of transistors used to make the logic gates, it might not be so obvious on first glance. If you look at higher level schematics, you need the labes to know what an IC does. Perhaps we need a set of symbols to describe patterns as well. Do the architecture description laguages do this?
Have you tried http://oreilly.com/catalog/9780596007126/?
Also a great intro, with real life examples and an easy way to remember the patterns.