After the introductory chapter, about the first third of the book discusses object oriented development. That's no contradiction: OO technology is usually the implementation vehicle for component systems. Szyperski adds (or at least collects) real content about OO technique, including the problematic relationship between 'contracts' and callbacks, language features for containment and control, and the many needs that current OO languages don't meet. Lots of the discussion sounds like 'the loyal opposition' - he supports OO practice, even demands it, but is harshly critical of the OO techniques that cause real problems.

The remainder of the book describes requirements of a workable component system and a workable component industry. If done right, component software really could solve a lot of problems: squabbling in multi-vendor environments, maintenance across multiple generations of releases, and more. The theoretical discussion is backed up with case studies, including JavaBeans, CORBA, and OpenDoc.

The would-be component user won't find a lot here; this book is really for the component or component framework developer. Developers, however, should not expect a lot of direct, technical detail. This discusses principles, not implementation. That's my one real disappointment in this book: the lack of detail. Even the case studies are brief and somewhat shallow. Those problems are easy to fix, however, with other books on specific APIs, systems, and development techniques.

If you are planning a component-based system, whether as a component user or a component developer, this book may be essential. It gives a complete, critical view of what components can do and what they should but cannot yet do. As you go through development, you'll come back to this book (or at least to its issues) again and again.

Then came the buzz-word SW Object Orientation. I first heard it in the mid 80s. To be frank about it, it had taken me about three years to get to the bottom of it. In my experience about 95% of the people who talked about it were either clueless or those who only wanted to jump on the fast track wagon.

In my view, the OO in its pure form is a little bit complex concept. Lets face it, when you start with a mean set of customer requirements and you have your boss breathing down your neck in some cases for no good reason, you are not going to be in the best frame of mind to look for SW objects in a bubble pool of analysis. OOD requires all kind of disciplines. Even the best OO design may not be supported by your target language and it may not be the best approach to your problem, what I'm mean that is like trying to dig your garden with a eating fork which may look like a garden fork !

Here comes the SW component part. Why not group the requirements into a set of likely entities ? Once the requirements are grouped in such fashion the SW Analysis elements are easily mapped onto what is called 'SW Components' which are well described in this book. The author is very descriptive about the idea and he is able to convey it in a simple manner. This book is not only about SW components it also covers other serious technologies such as SW Standards, differences in Components and Objects, SW design architecture, parallel and concurrency.

My comments here are related to SW System Developments, NOT System programming which requires different set of rules and support.

This book is for those who wish to learn about new technologies, the SW Components. It may not necessarily solve your current problems. At the end of the day there is never an optimal SW Technology which has all the best solutions for all the SW cases.