What do you think?
Rate this book
Designing Object Oriented C++ Applications Using The Booch Method
For senior/graduate level courses on Object Oriented Design using C++, and the Booch (BC) - OOD book. A practical, problem-solving approach to the fundamental concepts of Object Oriented Design and their application using C++. This book is written for the "engineer in the trenches". It is a serious guide for practitioners of Object-Oriented design. The style is narrative, and accessible for the beginner, and yet the topics are covered in enough depth to be relevant to the consumate designer. The principles of OOD explained, one by one, and then demonstrated with numerous examples and case studies.
- GenresProgramming
512 pages, Hardcover
First published February 15, 1995
1 person is currently reading
68 people want to read
About the author
Robert C. Martin
65 books1,886 followersRobert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 3 of 3 reviews
March 25, 2025
I acquired a used copy of this book because I realised that I'd been misattributing a favourite quote:
While I had already learned that before I bought the book, I still wanted to read it. In general, I don't think it wise to quote from sources that one hasn't read, because of the risk of misunderstanding the quote because one is unaware of the context from which it comes.
I admit that in the beginning, this mostly seemed like a chore. It's a thing I put myself through in order to consider myself intellectually honest. Reading the entire book wasn't a high priority for me, so I mostly kept it around so that I could make headway in it if I'd run out of my more common casual reading matter during lunch, such as newspapers, magazines, and the like. So, reading all the way through has taken some years.
Despite my initial misgivings, I soon realised that the book is better than I expected. At first glance, a book published in 1995, using C++ for example code, employing a 'method' no-one today has heard of, didn't seem likely to be valuable to a reader in the mid-2020s.
The first thing I noticed, however, was that this is recognisably an early Robert C. Martin work. I'm already well-acquainted with most of Martin's books, but I think that APPP was the earliest I'd read. This one is more than ten years younger, and I found it charming to see many of Martin's notions and didactic styles already on display in early stages of development. I ended up taking notes, also because I thought that some points about maintainability of source code was made better here than most other places.
I haven't written C++ code since the early 2000s, and I was never good at it. That turned out to be absolutely no barrier to my understanding, since all the C++ code was simple and easy to understand. The point of the book isn't to demonstrate advanced C++ techniques. Rather, its goal is to teach object-oriented analysis and design, and C++ is only one of two kinds of artefacts used to communicate ideas.
The other kind of artefact are sets of Booch diagrams. They are reminiscent of UML diagrams, but use different arrow-tips and shapes than UML. In practice, I didn't really care, because mostly, shapes with arrows are shapes with arrows, and such diagrams only work when accompanied by explanatory text. Which they are, here.
There are literally hundreds of diagrams, often one or two on a page, so in a sense, a page size of 528 is less daunting than it would otherwise seem. On the other hand, these diagrams aren't just pretty pictures. They do convey information, and you are best off paying some attention to them.
All that said, it's charming to see Martin deeply invested in what strikes me as a tedious and error-prone BDUF-like methodology when you know that only a few years later, Kent Beck would show him TDD, and he clearly didn't look back after that. All throughout I couldn't help thinking that a few tests and some static types sketched in F# or Haskell could have replaced most of those diagrams.
Apart from my choice of languages, I think that the Martin of today would agree with me.
Still, there are many insights to be had from the book, although chapters 6 and 7 seemed increasingly irrelevant to me, because they descended into specifics of implementation, and thankfully, a lot has happened since 1995. Most of the problems addressed in those two chapters seem like they could easily be addressed with modern languages, frameworks, libraries, and architectures.
"Abstraction is the elimination of the irrelevant and the amplification of the essential." (Martin's emphasis)For years, I thought that the quote came from Agile Principles, Patterns, and Practices in C#, but it turns out that that book only contains an echo of the quote. The real source is page 9 in Designing Object Oriented C++ Applications Using The Booch Method.
While I had already learned that before I bought the book, I still wanted to read it. In general, I don't think it wise to quote from sources that one hasn't read, because of the risk of misunderstanding the quote because one is unaware of the context from which it comes.
I admit that in the beginning, this mostly seemed like a chore. It's a thing I put myself through in order to consider myself intellectually honest. Reading the entire book wasn't a high priority for me, so I mostly kept it around so that I could make headway in it if I'd run out of my more common casual reading matter during lunch, such as newspapers, magazines, and the like. So, reading all the way through has taken some years.
Despite my initial misgivings, I soon realised that the book is better than I expected. At first glance, a book published in 1995, using C++ for example code, employing a 'method' no-one today has heard of, didn't seem likely to be valuable to a reader in the mid-2020s.
The first thing I noticed, however, was that this is recognisably an early Robert C. Martin work. I'm already well-acquainted with most of Martin's books, but I think that APPP was the earliest I'd read. This one is more than ten years younger, and I found it charming to see many of Martin's notions and didactic styles already on display in early stages of development. I ended up taking notes, also because I thought that some points about maintainability of source code was made better here than most other places.
I haven't written C++ code since the early 2000s, and I was never good at it. That turned out to be absolutely no barrier to my understanding, since all the C++ code was simple and easy to understand. The point of the book isn't to demonstrate advanced C++ techniques. Rather, its goal is to teach object-oriented analysis and design, and C++ is only one of two kinds of artefacts used to communicate ideas.
The other kind of artefact are sets of Booch diagrams. They are reminiscent of UML diagrams, but use different arrow-tips and shapes than UML. In practice, I didn't really care, because mostly, shapes with arrows are shapes with arrows, and such diagrams only work when accompanied by explanatory text. Which they are, here.
There are literally hundreds of diagrams, often one or two on a page, so in a sense, a page size of 528 is less daunting than it would otherwise seem. On the other hand, these diagrams aren't just pretty pictures. They do convey information, and you are best off paying some attention to them.
All that said, it's charming to see Martin deeply invested in what strikes me as a tedious and error-prone BDUF-like methodology when you know that only a few years later, Kent Beck would show him TDD, and he clearly didn't look back after that. All throughout I couldn't help thinking that a few tests and some static types sketched in F# or Haskell could have replaced most of those diagrams.
Apart from my choice of languages, I think that the Martin of today would agree with me.
Still, there are many insights to be had from the book, although chapters 6 and 7 seemed increasingly irrelevant to me, because they descended into specifics of implementation, and thankfully, a lot has happened since 1995. Most of the problems addressed in those two chapters seem like they could easily be addressed with modern languages, frameworks, libraries, and architectures.
July 13, 2021
Reading an old book from Uncle Bob was very interesting.
We can see that the SOLID principles were already there, even if they are not explicitly named.
There is also the Mark IV coffee maker that we find in the other books and videos.
Unfortunately, the examples are not very convincing and end up with long and complicated code.
I understand that Uncle Bob wanted to show realistic examples, but I wonder how many readers could stand the complexity of the security system till the end of the book.
Nevertheless, this book shows Martin's amazing writing skills: clear, simple, fluid, and please to read.
My overall impression is that is book was the draft for Agile Software Development, Principles, Patterns, and Practices
We can see that the SOLID principles were already there, even if they are not explicitly named.
There is also the Mark IV coffee maker that we find in the other books and videos.
Unfortunately, the examples are not very convincing and end up with long and complicated code.
I understand that Uncle Bob wanted to show realistic examples, but I wonder how many readers could stand the complexity of the security system till the end of the book.
Nevertheless, this book shows Martin's amazing writing skills: clear, simple, fluid, and please to read.
My overall impression is that is book was the draft for Agile Software Development, Principles, Patterns, and Practices
May 11, 2013
A bit old now, but this book had a dramatic impact in how I thought about programming back when I read it in college. I picked it up after having completed a course which was supposed to teach object oriented programming and feeling I'd gotten nothing out of it. This book fixed the problem and then some.
Displaying 1 - 3 of 3 reviews