BCA Month Beauty Fall Reading Hallo nav_sap_hiltonhonors_launch Learn more about Amazon Music Unlimited PCB for Musical Instruments $69.99 Grocery Handmade Gift Shop hgg17 Save $30 on a Deep Cleaning Appointment outlanders3premiere outlanders3premierealtText Watch Outlander on Starz with Amazon Channels outlanders3premierealtText Watch Outlander on Starz with Amazon Channels  Three new members of the Echo family Now shipping All-New Fire HD 10 with Alexa hands-free $149.99 All-New Kindle Oasis South Park Shop Now HTL17_gno

Customer reviews

4.3 out of 5 stars
Large-Scale C++ Software Design
Format: Paperback|Change
Price:$62.63+ Free shipping with Amazon Prime

on June 28, 2017
A truly ground-breaking book in 1996, it is no less useful today as a guide to, well, as the title says, large-scale software design. And although some of the concepts and implementation ideas are specific to the C/C++ family of languages, the principles are, to a surprising extent, language neutral. Even in the cases where the build/interpret systems of other languages would allow relaxing some of the design rules with no manifest issues, virtually all of the rules contribute to arbitrarily large software systems that are easy to use, understand, and maintain. This book is a must-read for every student and professional who aspires to the title of software engineer.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on June 5, 2015
One of the few texts in the literature to deal with development and quality issues that arise in large C++ projects.
It introduces the concept of component and package as the unit of physical design. On this concepts the text develops extremely valuable design rules, practices and techniques (to name a few: factoring, escalating encapsulation, protocol classes, fully insulating concrete classes) to obtain critical qualities (like levelization and insulation) for large-scale C++ projects.
The text gives also rules and techniques that address logical design issues in perfect harmony with the techniques related to physical design issues.

Although it was written back in 1997, the book remains as timely as ever, given that exposes the same problems that justify the likely introduction of Contracts and Modules in the next C++17 standard.

I strongly recommend the book to any C++ developer who wants to take advantage of the precious experience gained by the author in the context of really large C++ projects.
0Comment|Was this review helpful to you?YesNoReport abuse
on October 4, 2015
quintesential fare if you lead huge, complex software projects, not even in C++. The style is glutonous and some of the material presented as religious truths while they are simply experi3nce based opinions. The structure laid out however exposes some of the 'laws of physics of large software bodies' and is therefore a must read for a _practicing_ architect, i.e. not someone who stays in 'models' only but is concerned how to get the actual code to work and be maintianble over long periods of time.
0Comment|Was this review helpful to you?YesNoReport abuse
on July 23, 2002
This book is a must-read for any serious C++ programmer. Why? Because it is the only decent treatment of physical C++ design available.
Physical design issues, if not addressed, will inexorably cripple any sufficiently complex, performance-sensitive C++ project. Moreover, there is never any time to worry about physical design quality in the heat of battle, so you really need to deal with it up front.
Having said that, the book is not without its flaws.
First, the age of the text is evident. It doesn't address the interchangeability of typedefs and classes for certain purposes, it doesn't fully appreciate the power of namespaces, and it is rife with "the World didn't go that way" conventions. Fortunately, this doesn't prevent the book from getting its point across, but you do need to take some of its "rules" with a grain of salt.
Second, it's longer than it needs to be. This isn't so much of a liability, because it reads faster as a result. Still, its redundancy and long-windedness is sometimes tedious.
But all in all, if you've bothered to read this review, then you probably ought to own a copy of this book.
11 comment| 55 people found this helpful. Was this review helpful to you?YesNoReport abuse
on June 9, 2015
This book was recommended to me by a professor. It is very enlightening book about OOP programming and even though this books older it is very much in line with a lot of videos I am seeing online. I would recommend this book if you have programmed your self into a corner multiple times with C++ or another OOP language.
0Comment|Was this review helpful to you?YesNoReport abuse
on January 31, 2015
Good book but a bit dated. Modern C++ features have obsoleted some of the advice in here, but the focus is right. I'm looking forward to the next edition of this, due out some time soon.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on January 5, 2006
I read this book back in 1998. It is the foundation for my understanding of the design of object oriented software. Prior to reading this book I programmed in C++ for more than 8 years. It was apparent to me that there were gaps in my understanding of how to design medium and large scale object oriented systems. This is a huge and dense book, but as I read through it, many times a light went on in my head (those ah ha moments).

The book also gives specific details about consideration for the C++ language. C++ has changed over the years, and the examples do not use newer language features. I do not feel that this is important. The code clearly illustrates the ideas, which are not limited by the state of C++ at the time the code was written.

Regardless of the object oriented language you use to develop software this book will teach invaluable concepts that I have not found explained elsewhere.
0Comment| 11 people found this helpful. Was this review helpful to you?YesNoReport abuse
on March 28, 2008
This is a superb book on software design. While clearly intended for those working on large-scale projects with a broad base of users, the principles discussed are rock solid for even the smallest project. It illustrates a higher level of C++ where objects are not just used because they can represent complex concepts nicely but because proper object-orientation is insurance against many coding evils - exactly the evils which can sabotage large-scale software projects.
0Comment|Was this review helpful to you?YesNoReport abuse
Excellent book! Even though of old, It's good condition!
0Comment|Was this review helpful to you?YesNoReport abuse
on February 17, 2010
I am extremely sad for what I am about to say, but unfortunately this book has lost most if not all of its relevance over the last 15 years. I don't think today is a very useful book to read anymore.

I read a few books on and around C++ (say the 4 Sutter's, the 2 Alexandrescu's, the 3 Meyers, many parts of Knuth's Art of Computer Programming, Kernighan and Pike, Refactoring, Design Patterns, Analysis Patterns) and maybe about a half of this book. A this point I stopped. Note that this is well into the physical design part, which was the reason I bought this book in the first place. I am extremely disappointed with the book, enough that this is probably the first time I don't finish a programming book.

There are two principal bad points about this book: one is the density is way too low, the book is about 600 pages, the same stuff should have been edited down to maybe 250 (one could say this is the editor's job, btw, but still it's our time which is not made best use of). The other one is that most of what the author talks about are either suggestions for protocols that nobody would use today (take the proposed iterator interface: since the STL became standard, nobody iterates like Lakos suggests anymore) or, worse, based on circumstantial evidence of the system the author was using at that time: a lot of the book is concerned with reducing inclusion dependencies which in the text is mostly supported by a measurement the author made on his system, and then marginally by the necessity of being able to undergo low costs when moving files around a project for reuse (which instead, on its own, is a pretty good point: if there's too many complex inclusion dependencies, relocating a file for refactoring, or pulling it into a different project can become a nightmare).

Unfortunately he took a seriously wrong choice to attack his problem: he chose to manually solve the problem with various tricks and hacks such as external include guards, instead of building himself a simple tool like a pre-preprocessor or something of the kind. Needless to say, for the case in point, modern compilers have no need for such guards, as single inclusion is built into all the (current) tool chains I know *OF* (let alone the ones I use!) (this is necessary for building big systems, because headers could reside on a network, and it would be unwise to pull the same file across multiple times, once you have the file across, you parse it once, and then use it as necessary). So yes, he deserves the credit for identifying a problem (assuming he's been the first to describe it), but most certainly not much credit for the solutions proposed.

While reading, I have spent copious amounts of energy trying to salvage in my mind the most from what the author suggests, but I gave up, under the impression that the update work needed was quite more than the information that could be kept unchanged.

At this point I went back, and reread all the reviews on Amazon and figured that the part I read was actually the "good" one, while the section on logic design was even more out of date, and this is where I stopped reading.

Summing up, the one good point of the book is outlining that headers can be thought of as graphs of dependencies, and that keeping these graphs as acyclic as possible solves so many problems that it's for sure well worth including as one of the primary design goals in a project. A few techniques are shown on how to achieve this goal. Some are of some value, none was particularly non-obvious (any simple technique in Sutter, Meyers or Alexandrescu is quite more sophisticated than what's discussed here).

So, any book that pointed out what I said in the phrase above is worth maybe two stars, this author lost one due to his complete inability to summarize and come directly to a point. One extra star was then added in consideration to the person who so warmly recommended this book, as he is a very experienced programmer.

By the way, I realized after the fact that I have also been (in the past) a user of one of the packages from the company the author was working for, as well as a couple of competitor and more or less equivalent packages. I most definitely cannot say that *from the user experience standpoint* the product was any better than the others, actually it seemed quite disrespectful of standard platform conventions for default file storage, for example.

One last word:
I'm not sure this is relevant to all readers, but the style and typography of this book are surprisingly poor. The text is set too big and is poorly spaced, there are too many visual jumps in spacing and density, many pictures are related to text in a non-visible page (typically the previous one) and most pictures are way too big for the little information they represent. For a book that has received this level of credit (and a publisher of otherwise rather beautiful books) I had expected a *much* better look and feel than this.

Other Resources:
I think a more modern replacement for this book would be Sutter and Alexandrescu's "C++ Coding Standards", which does not have an explicit part on physical design issues, but gives you enough food for thought to build yourself quite naturally good practices in that domain based on the rest of the discussion. One of their opening points is "don't sweat the small stuff". Great advice.
22 comments| 65 people found this helpful. Was this review helpful to you?YesNoReport abuse