Component Software Beyond Object Oriented Programming

Component Software : Beyond Object-Oriented Programming by Clemens Szyperski

ISBN 0201178885 This new book has been touted as a paradigm-shifter, but after looking through it, I'm not too sure. The author, ClemensSzyperski, tries to make the case that BlackBoxComponentry will supersede object oriented programming. For a variety of economic reasons this would make sense, and he surely does point out some interesting pitfalls of whitebox reuse via inheritance. The problem is that he more or less concedes that whitebox is easier, points out that getting semantic specifications correct enough to do independent extensibility is an open topic, and that designs based on composition tend to get dense and obfuscated.

I wonder whether economics is enough to push a technology that requires more restrictive development over one that is easier to use.

A very interesting read, and strong on technical issues. It contains the best defense of MicrosoftCorporation's ComponentObjectModel that I've seen in print. It points out how biting the bullet and making interfaces immutable (and branding them with GUIDs) helps in attacking a whole host of reliability and versioning issues that are hard to deal with any other way. -- MichaelFeathers

Does it do a better job than http://msdn.microsoft.com/library/techart/msdn_aboutole.htm ?

Yes, that is probably a better explanation. Clemens takes it from a more conceptual tack, but anyone who reads the reference above will get the same points. It is nice to see someone present it against the backdrop of OO theory and research. I've seen so many people who just notice that there is no inheritance and interfaces are immutable. Then they just say "well it isn't OO" and leave it at that. -- MichaelFeathers

Will BlackBoxComponentry supersede ObjectOrientedProgramming? I don't think so, for the very simple reason that OO and black box componentry aren't trying to do the same things (see OoIsNotAboutReuse). It is important to understand, however, that the two are complementary. A black box component may well have an object-oriented design under the hood, and if it does anything very complicated at all, it very likely does. Also, an application may make heavy use of black box components for part of its functionality, while other parts might be written the old fashioned way by the application's developers; these other parts might well be OO. -- CurtisBartley

I agree. My way of thinking about this is that you have a problem to solve and you need to build a system that solves that problem. Lots of times you can't just think about the entire solution in terms of one chunk, so you naturally break it up into smaller chunks that interact to form a cohesive whole.

Once you do that, and you've got to implement the behavior behind each of these chunks, you start specifying it in terms of a language. Many times with CBD it's an OO language because a class encapsulates state and behavior much like a component can. We've had extensive arguments on this subject in other pages (see ComponentDesignPatternsStupidQuestions).

Finally, there are only so many classes you can define before you get down to primitive data types, so you implement your classes in terms of these primitive types, or allow them to relate to other classes (that at some point probably have primitive types as well). At the end of the day you're just breaking up a big problem into smaller and smaller chunks, and you're free to use different paradigms while doing so.

I see a similarity to the way Alexander breaks up his pattern language first into regions, and towns, then into neighborhoods, and buildings, and gardens, rooms, etc. Albeit for fairly different reasons, the similarity is that at all levels we are trying to help solve the problem of keeping structures alive.

--PhilipEskelin