Applying UML and Patterns
After reading The Object Primer and Building Object Applications That Work, I still felt that I was not truly understanding object-oriented programming. My last shot was to read Applying UML and Patterns. This book is a lot better than the first two, but it still makes what I believe is a fundamental mistake in its approach. Its mistaken approach is to tell me what to do, when the right approach is to teach me what to do. This mistake is made by most programming books, so it may seem unfair to criticise Craig Larman. However, the next book I will talk about takes the right approach, and the difference between the two books is huge.
As I write this, I have both books at my side. Because I am writing a number of blog entries in order to bring the story of Charlie up to date, I have been flipping through these books to remember what precisely I learned from them. As I flipped through Applying UML and Patterns just now, I thought to myself, “I don't remember any of this. Did I really read it?” Well, I did read it, and only about six weeks ago! I then picked up the other book, which I will talk about in my next weblog entry. As I flipped through it, I thought to myself, “I remember all of this! Was it really six months ago that I read it?”
I have been thinking about why I remember virtually everything in a book I read six months ago, and virtually nothing from a book I read six weeks ago. They both cover the concept of design patterns, so the difference is not in the material. The difference is in the approach. Larman’s book tells me what to do. The other book teaches me what to do.
But in fairness to Craig Larman, I did get some ideas out of Applying UML and Patterns, just as I got some ideas out of Scott Amber’s two books.
First, the book provides a helpful overview of the technique suggested by Russell Abbott regarding how to identify objects. If we look at a written description of the use of our software, the nouns in that description are candidates for the software’s business objects. By way of example, here is a description of how a web surfer may use a Charlie website:
“The user can view an article and leave a comment.”
Pretty simple, huh? However, if we highlight the nouns in that description, we have very good candidates for business objects:
“The user can view an article and leave a comment.”
While I already knew about this approach, the approach is so simple yet so helpful that it represents one of the highlights of the book.
The real strength of the book however is its categorisation of design patterns.
It has been said that there are only three original stories in the world. (In truth, I cannot remember the precise number, but it was a very small number.) Every story ever told is a variation on one of these three original stories. (For example, every crime story is a variation of the “good versus evil” story, and every romance story is a variation of the “love versus adversity” story.)
The insight provided by Craig Larman in his book is that there are nine basic software design patterns (what he calls the nine GRASP patterns). All design patterns are a variation on one or more of these nine basic design patterns, just like all stories are a variation on one of the three basic stories. By distilling the plethora design patterns down to just nine, Craig has brought order and meaning to the ever-expanding topic of software patterns.
Even better, Craig focuses on why these patterns exist. Understanding why patterns exist is crucial to applying patterns. If a developer applies the Model-View-Controller pattern because all the cool kids seem to be doing it, then he has misused the pattern. Conversely, if another developer understands why the MVC pattern exists, then she may come up with a unique twist to the pattern that is precisely right for her application. A pattern is not meant to be cookie-cutter answer to a software problem. A pattern is meant to be kneaded, rolled, and massaged until it produces an appropriate solution to a specific problem.
I should point out that even though the book talks about a number of well-known design patterns, this is not the right book by which to learn design patterns. If a developer already knows about patterns, then the categorisation of all patterns into the nine basic GRASP patterns will be helpful. But if a developer does not already know about patterns, I doubt he or she will be much the wiser after reading this book.
Finally, a warning. This book is even more forceful in its promotion of UML and the Agile development process than the books by Scott Ambler. I guess that’s excusable, since UML is in the book's title. But if these authors are trying to promote UML and Agile development, they are doing a poor job of it. They make UML and Agile development out to be monstrously complex. In a Peanuts comic, Charlie Brown says that the secret to life is to replace one worry with another. That seems to be an apt description of UML. Take the worry of software design, and replace it with the worry of UML. No thanks, and please stop trying to sell me on the idea.
by Alister Jones | Next up: Head First Design Patterns →
----
Post a Comment