Salon Beauty Best Books of the Year So Far Introducing Prime Wardrobe nav_sap_plcc_ascpsc The Carters Fire TV Grocery Handmade Personalized Jewelry Home and Garden Book a house cleaner for 2 or more hours on Amazon TheGrandTour TheGrandTour TheGrandTour  Echo Fire tablets: Designed for entertainment Kindle Paperwhite GNO Shop now Start your Baby Registry

Customer Reviews

4.3 out of 5 stars

on April 12, 2015
Are you trying to get up to speed on that great post-object-oriented buzzword, "component?" Pick up a copy of Clemens Szyperski's Component Software: Beyond Object-Oriented Programming and you'll walk away thoroughly grounded in component technology. Component Software is very readable, yet Szyperski leaves no stones unturned in this thorough view of components, how they're different from objects, and why component-based development is a Good Thing. He also discusses the component market's viability, analogous to today's trade in ActiveX components, and how such a market would develop. Unfortunately, even though the book was just published in 1998, it's already out of date' for example, no mention of Java 2'but that's unavoidable given the rapid pace of development. It also doesn't cover component modeling or modeling languages such as UML.

What I like most about Component Software is that it provides a solid theoretical underpinning for understanding components and then gets practical' discussing the current instantiations of the Object Management Group's CORBA and OMA; Microsoft's DCOM, OLE, and ActiveX; and Sun's Java and JavaBean approaches to component technology. He similarly treats component frameworks, covering the sadly lamented OpenDoc as well as BlackBox Component Builder, and compares Java and Component Pascal, two languages used for component development.

That brings up what I liked least about this book: Szyperski is co-founder and director of research at Oberon Microsystems (, a spin-off from ETH Zrich, which makes, among other things, BlackBox Component Builder and Component Pascal. Comparisons of Oberon's technologies against other approaches are somewhat one-sided. Szyperski also shows a subtle (perhaps unconscious) bias towards Microsoft's COM approach.

Those lapses are more than offset by excellent work, such as outstanding chapters on objects vs. class inheritance, open problems working against component adoption, and component-based development. If you're looking for one definitive book on component technologies, this is that book.
|0Comment|Report abuse
Szyperski has written a truly outstanding introduction to component software systems. This is the most complete, clearest introduction to the basic problems and practice of component software development that I've seen.
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.
6 people found this helpful
|0Comment|Report abuse
on January 27, 1998
If found this book very enlightening. It is the first book I have seen that discusses component oriented software in a real world way. Mind you this is a text book, not your typical programming book, so some of its appeal will be limited. However, for anyone doing any serious thinking about component software this book is a must read.
The author (one of the principles behind Oberon and Component Pascal) very carefully avoids taking explicit sides in the so-called "component wars" (the same cannot be said about his stance on objects v. components, he clearly believes OO has failed to live up to its promises). However, I think the book is (indirectly) about Microsoft's COM in that it explains, in a very detailed, academic sort of way, the same principles that are behind COM. I don't think the author intended to write a book about COM, it's just that his ideas and the ideas of the designers of COM appear to be very similar.
At 28 chapters & 411 pages this is a long book. It covers a lot of material. Some parts are pretty hard to read because they are so academically grounded. The author recognizes this and warns the reader beforehand. Most of the sections I found hard to read could easily be skipped over without detracting from the real value the book provides.
13 people found this helpful
|0Comment|Report abuse
on May 24, 2003
When I started SW Engineering the SW functional decomposition methods were in fashion. People became relatively quickly familiar with them, and we developed our SW on Intel's 8086 based chip sets, with a few Ks of memory. The programming practices were reinforced by our peers and the Management.
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.
5 people found this helpful
|0Comment|Report abuse
VINE VOICEon September 6, 2010
I searched for a book that would fill in the details about what I already felt, and was learning from a colleague: that to create software components you don't need classes. My efforts were rewarded when I saw the titles of chapters 1 and 7:

1.1 Components are for composition
7. Object versus class composition, or how to avoid inheritance

and further,

7.1 Inheritance -- the soup of the day?

Component Software: Beyond Object-Oriented Programming goes back to first principles and requirements -- what we really want from software development, how such design methods would look, and then, in the later chapters that I only skimmed, how it might be done in current languages and frameworks. Bonus of understanding: why what's popularly known as "Object-Oriented" programming is really only "Inheritance-Based" programming. For software architects, and for developers who are early adopters, risk-takers, or inventors of better ways to code, well worth checking out this book.

Full disclosure: I only had time to read the first third of the book before I had to move on to other topics.
2 people found this helpful
|0Comment|Report abuse
on May 25, 2000
The main objective of the book is to present software components and their importance in software engineering mainly for reuse purpose. To a large extent, this objective has been achieved. The book is a fairly good and complete coverage of many technical (foundations, approaches, implementation, standards, etc.) and non-technical aspects (markets, billing, professions, etc.) of software components. The presentation of the three major approaches for software components, i.e., OMG CORBA, Sun Java and Microsoft COM, and their comparison are very valuable especially when one has to choose one of this approach in building component-based systems. The discussion of non- technical aspects, especially, the market issue is a plus in such types of books.
In this book, systematic reuse is viewed as how to build reusable asset consisting primarily of software components. Reuse is mostly viewed through implementation inheritance and object composition with forwarding or delegation in the object-oriented sense. In that respect, the book goes into many details related to objects. While objects are tightly related to software components from the author's point of view, it is sometimes not clear how the presented discussion is useful for actually building reusable components. Also, sometimes the reader may lost the relationship and differences between objects and components. On the other hand, the author should have discussed in more details the importance of software components in the general area of software reuse. In particular, will software components based on objects be the only way to build reusable components. There are also a number of software engineering issues that should receive more attention regarding the reuse of components. These concern library or catalog of components and quality measurement of components.
The book is well organized, but I think that short chapters should be grouped together. This is especially the case for the last part. Also, one of the problem that I had while reading the book is that in some instances the link between successive sections is not well done. Finally, in my opinion, many of the chapters in part two, three and four should be read in two passes, a first quick pass and a second more deep reading. This will enable the reader to get a maximum benefit from them.
20 people found this helpful
|0Comment|Report abuse
on July 26, 1998
Szyperski's book discusses component software from an unusual point of view: as an academic and a professional. This perspective provides the reader with the best of both worlds: a discussion of essential academic object and component concepts as well as a pragmatic review of existing component systems. In particular, the important topics that Szyperski covers include callbacks and their impact on reuse, reentrant code, component interface specification with contracts, subtyping (co/contravariance), code and behavioral inheritance, and finally safety and progress specifications. Each of these topics is critical to the development of robust and reusable components. Szyperski's discussion of todays' component frameworks (loosely, CORBA, COM, and Java) shows his biases, but they are objectively justified. Finally, the author discusses the next generation of component architectures. Included in this discussion is a brief foray into OpenDoc! , a discussion of Oberon Microsystems' BlackBox component framework, and Portos and Denia, two hard realtime component frameworks. Any designer or developer that uses or builds components must read this book. It will help the good component designer/developer/manager become a _great_ component thinker.
9 people found this helpful
|0Comment|Report abuse
on May 15, 1998
A beautifully written and researched book, Component Software is a fascinating study of the practical aspects of making components work in software development. Touching on Java, CORBA, COM, architectures, frameworks, component assembly, domain standards and much more, the author gives the reader an impressive panaroma of the state-of-the-art in component technology.....But this doesn't do justice to the expressiveness, insight, and impressive range of integration between fields of component study that Szyperski puts into this book. You will not find a more useful addition to your library about component technology and we recommend it strongly. -- Object News Book Reviews
4 people found this helpful
|0Comment|Report abuse
on December 19, 2002
If you are wondering what a component is - READ THIS BOOK! It gives you an excellent foundation of components and component technologies irrespective of any particular implementation or commercial product. It will allow you to distinguish between component systems and those that are not. C. J. Date's book on the definition and properties of relational database systems was a landmark book. This book does the same for component technologies. Get smarter - get this book. Totally Awesome!
|0Comment|Report abuse
on December 16, 1998
I got this book by almost by accident waiting for one of those Japanesse Fish barns to open.
It explained many of the issues that occur in OO development - problems with extreme re-use - fragile base class problem, "changing the way you do business" and many others. I actually found these non-component chapters in some ways more useful than the others.
Then went on to discuss components in a very concrete and thorough way. It gives enough info in order to make a real judgement on whether to embrace components or not.
I would buy it again for either of the two reasons.
7 people found this helpful
|0Comment|Report abuse