ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1949 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Component Software
Clemens Szyperski
0 201 17888 5
Francis Glassborow
object oriented; CORBA and COM
Appeared in:
Once you have mastered object-oriented programming there are two directions competing for your attention. On the one side we have the Pattern Movement aiming at communicating fundamentally sound software design principles to the working programmer. A major motivation in the development of patterns is to help the less than master programmer (less than 1 in a thousand working programmers) to capitalise on the work and design understanding of that elite.

On the other side we have the developing concept of software components. Let me give you a trivial example from a different engineering expertise. When designing a computer, do not place the CPU under the power supply. Doing so will cause you heating problems. Or, if plugging an element in the wrong way round can cause damage use a shaped plug that will not go in the wrong way. The experienced PC designer could come up with a range of other 'rules of thumb'. These are patterns for computer hardware design. I wish that more designers would learn not to put RAM sockets under hard- drives - I get tired of dismantling a machine to add some extra RAM.

Alongside design issues we have ones of using the work of others. I want to be able to pull out one CPU and simply plug in another. I do not really care about the internal differences between an Intel Pentium MMX chip and an AMD K6. This is component level thinking. Well-designed components with consistent and compatible interfaces reduce costs and (though they hate it) enhance competition. I want to be able to replace a component from one source by the next generation from the same or alternative source. This means that we need well-designed interfaces. There are a number of component technologies developing at the moment. Three major contenders are JavaBeans (a Java specific component technology) DCOM and ActiveX from Microsoft and OMG's CORBA and IIOP. Will there be an eventual winner? Or will there be some form of universal connector that can adapt to whatever components are at the ends? I have no idea.

If you want to learn more about the technical and business issues at stake in this area will benefit from taking time to read this book.