1.1 MY GOSH, WHAT HAPPENED?

We may never learn the complete story of what actually happened with Mentor: perhaps the paradigm shift was difficult for programmers involved in the original project, or per- haps the old style of managing software development was not applicable to object-oriented technology.

After talking privately to many employees involved in the project, I have concluded that the central data organization which formed the backbone of the entire system (you can call it a database or a framework) was simply too complicated. It included many mutually inter- acting classes which could not be tested independently, and the software became tOO com- plex even for its own creators.

Though this view has never been officially confirmed, the experience shook not only the company, but the entire programming community. Object-oriented programming is supposed to create a more productive environment, and lead to safer, more reusable code. Many people began to wonder: Is object-oriented programming really a step forward? Mentor Graphics was not the only company that encountered problems in using C++. In its Executive Briefsection, Object Magazinet published the following paragraph: " 1992 was, by all accounts, a year of trial for both Borland International and object programming . . . company's ambitious plan to rewrite its products using object tools had taken about eight months longer than expected. That delay, combined with financial worries caused by expensive acquisitions, sent Borland's stock into a recent nosedive and spurred both layoffs and significant organiza- tional changes . . . Once the transition to object-based products is complete, they (market ana- lysts) say, Borland's strong technology base should allow it to ship reliable upgrades faster."

At the 1991 OOPSLA conference, other users reported difficulties with the implemen- tation of C++ projects. Software managers at some companies panicked, putting C++ devel- opment on indefinite hold.

At the 1992 OOPSLA conference, Andrew Koenig, one of the AT&T C++ apostles, pub- licly admitted that, in his opinion, certain situations are difficult to handle in C++, and he pointed to the classical data structures as a typical example. This statement points in the same direction as my observation about the Mentor project. Projects which employ complex internal data may increase the logical complexity beyond acceptable (maintainable) levels.

What made the Mentor situation especially interesting was that the programmers were not amateurs. Many of them had been using C++ since 1984. Also, the AT&T C++ team recognized this project as one of the first truly large C++ projects outside of AT&T, and provided special guidance and assistance.

The subject of this book is how to use C++ so that similar problems can be avoided. The discussion is based on the theory and practical experience available today, but is definitely not exhaustive. It reflects the author's personal opinion, and it offers solutions for the prob- lems that may be considered to be most critical today.

There are two central themes: cyclic dependency between classes greatly increases the complexity of software; and persistent data and data structures (class patterns) share many implementation problems. We will discuss the implementation of Booch's mechanisms (patterns), efficient class libraries for polylithic data structures, and the impact of inheri- tance and virtual functions on program maintenance and debugging. We will also describe several approaches to persistent data, including in-depth programming details.

This book stresses the importance of code clarity. In addition to driving the hardware, a computer program can be viewed as a precise record of the algorithm that solves a given problem. If the algorithm cannot be understood by reading the code, something has gone terribly wrong.

Even though this may appear contradictory, readability is essential even in situations when the code has been modified to improve performance. Such code often involves com- plex logic, and the source is its only documentation.

You will quickly find that this book is easier to read than you might expect, judging from its size. It includes many code listings in which you often may be able to see the main idea without studying every line. There are two reasons why most examples contain full running programs: they allow you to verify that the programs really work, and they do not leave any tricky details to your imagination.

This book views object-oriented programming (and C++) as an extension of previous programming experience and methodology, rather than as a replacement for everything that has been done so far, as is sometimes presented.

The reader should have a basic knowledge of C++. Advanced professional programmers will benefit from the book, as well as beginners and students.