Rajesh Pradhan
At runtime, we expect to have a single instance of a component instantiated at a nearby (or faraway) server, and that this one ‘runtime’ instance is supposed to provide all the functionality expected of the component through its interface. Objects, on the other hand (and here I am using the word objects interchangeably with classes – while fully knowing the difference between the two) can be instantiated multiple times, and may reside on one or more machines. Thus, there appears to be a distinct difference between what is called a component (a single runtime entity providing all functionality) and an object (of which multiple copies can be instantiated, and which may go in and out of scope during the execution of a thread of sequence).
During development, though, my experience has been that a component translates more or less to a ‘collection of objects’. We are able to use the same concepts of objects, object relationships, object stereotypes etc. and apply them successfully to a ‘group of objects’ or a component. Patterns, which can be applied to create components, can also be used to create a group of objects. Thus, during development, components and objects are not much different, except for the fact that a component is a collection of objects.
Biographic sketch
Rajesh Pradhan heads the Center for Object Technology Excellence (COTE) for CASE digital in India. Rajesh has over 8 years of practical experience in leading a team of more than 30 software engineers for in-house and offshore projects for CASE digital in India, UK, Australia and the USA.
Clemens Szyperski
Are apples oranges? Or even: Are apples better oranges? I assume most would be inclined to say no. However, the answer depends — it depends on the degree of abstraction chosen and on the intention of the definition. Indeed, apples aren’t apples, if a viewpoint is taken that emphasizes the individual apple’s properties. Likewise, oranges can be better oranges.
When facing the question this panel is faced with, the first question has to be "What is the intention in distinguishing objects from anything else — and what is the intention in distinguishing components from anything else?" Then, should the answers to these two questions turn out to be similar, we can proceed to ask the original question — relative to the intentions. Here is my (overly brief) take at the intentions behind the notions of objects and components. Both, I hope, are not surprising.
Objects form abstractions over identifiable parts of a state space: they have a unique identity and they encapsulate the variables and operations over those variables that define the abstracted part of the state space. Hence, no two objects occupy the same partition of the universal state space.
Components form abstractions over namable parts of a deployment space: they have a name but not a unique identity; they encapsulate static implementation decisions and are restricted to explicitly specified dependencies on other components only and, preferably, have dependencies that are configurable ("connectable").
If objects and components are so obviously separate, then the question whether components are better objects needs to be unasked. Where did the confusion of objects and components originate? The most likely cause is their similar appearance in abstract modeling. Both have the encapsulating properties that establish the respective partitioning. Both are accessed via well-defined interfaces. However, components do not normally directly service their interfaces, unless these interfaces are traditional procedural (or functional) APIs. Instead, components service many interfaces indirectly by supplying object implementations (classes) and other resources. This is why components and objects should be seen in a synergistic way.
Biographic sketch
Dr. Clemens Szyperski is a Research Software Architect with Microsoft Research, Redmond, Washington and an adjunct professor with Queensland University of Technology, Brisbane, Australia. He is the author of the best-selling and award-winning book "Component Software: Beyond Object-Oriented Programming" (Addison Wesley 1998). He has published numerous papers and has been a frequent speaker at academic and industrial conferences.
Antero Taivalsaari
Component-based software development has always been a somewhat controversial topic. For the purposes of this discussion, I define components simply as reusable, binary units of software distribution. In principle, components do not have to be based on object technology, but in practice the life of a software engineer becomes much easier if they are.
Also, even though the limitations of the modeling capabilities of object-oriented languages are quite well known, the object-oriented paradigm still provides the best abstraction mechanisms for modeling real-world business applications in a reasonably natural way. Consequently, to me the question is not so much if components are objects. Components should be based on object technology. However, there are currently two major threats to the success of object technology, and hence also to component-based software development.
One of these threats is the rapid transition toward web-based software development. The web, as we know it today, is not based on objects. Rather, the web is a combination of diverse, low-level technologies that provide poor support for abstraction and application development in a systematic fashion. The other threat to object and component technology is the transition toward ubiquitous, wireless, mobile computer systems. Because these systems are typically heavily resource-constrained, people often erroneously assume that object and component technologies are too heavyweight for these systems.
The object-oriented community should work hard in order to prove the technical feasibility of object technology in the context of the web and Internet appliances. Without a more consistent, higher-level technological base, the promise of widespread component-based software development will not happen anytime soon.
Biographic sketch
Antero Taivalsaari has studied object-oriented technology for the past 12 years, first as an academic researcher and later in the industry in Europe, Canada and USA. He has worked as a research manager at Nokia and joined Sun Microsystems in 1997 where he now leads the KVM development effort, which he helped co-start at Sun Labs.
Alan Wills
What are the interesting principles common to, and different between the object and component design disciplines?
To make a flexible software system that can easily be changed, build it from different pieces; and importantly, make the variability in the requirements correspond to the pieces of the software.
For me, a component is part of a kit. You assemble various end-products by choosing components from the kit, and plugging them together.
How the components and their plugpoints work is not important; the whole thing could be in Cobol, SQL, Java, or some mixture. These pieces could be objects or components: the design principle is the same.
Pluggability is an OOD principle that's strongly emphasized in component-based development, and the technology of interface definitions supports it well.
One of the big advances of component technology is that it has extended the scope of object design outside the range of a single execution space; object designs can cross language boundaries too.
In summary:
- Separation of concerns is a fundamental design principle; objects and components both encapsulate state with operations, and the technique of deciding responsibilities and collaborations work for both of them.
- A component is part of a kit, which defines a common set of protocols between its members.
Biographic sketch
Alan Cameron Wills is joint creator of the Catalysis approach to object and component based design (with Desmond D'Souza). He has been a consultant since 1992, working with clients in a variety of fields in Europe and the USA. He is a principal consultant with TriReme, a UK-based consultancy.
