contact us
about us
site map


SOA & UML course in Stockport
(near Manchester)

22nd September 2008

Web Usability Patterns Site

Web Usability Products & Services

A comprehensive tutorial on UML

your requirementscustom solutionsexpert helpwhitepapers

 objects Vs components


Is there a difference between objects and components?

A report by Ian Graham

This paper summarises the discussion that took place at a session of OT99 in Oxford, England on March 29th 1999. The session set out to explore the issue of whether the recent emphasis on components is justified as something genuinely different from object technology or merely supplier-motivated hype. Participants were invited to air their opinions and debate this and the following auxiliary questions:

  • What exactly is the difference, if any, between a component and an object?
  • Do components delivered as binaries which cannot be modified by inheritance throw away most of the advantages of object-oriented programming?
  • What is the ideal granularity of components, if there is one?
  • What effect does the component viewpoint have on language design and language selection?
  • Are IDL semantics rich enough to describe ‘business object’ components?
  • What are the implications for object-oriented methods?

The initial participants were:
Peter Jones (Bezant Ltd.)
Andrew Watson (OMG)
Alan O’Callaghan (De Montfort University)
Alan Wills (Trireme Ltd.)
Microsoft Inc. were invited to participate but declined.
The session leader was Ian Graham (Ian Graham Associates Ltd.)
The majority of those attending (about 35) contributed to the discussion at some point.

Peter Jones kicked off, pointing out that the concept and term COMPONENT had a history just as long as that of OBJECT, referring to a 1967 NATO conference. He went on to try to distinguish objects from components by saying first that component systems are extended by composition rather than inheritance and then elaborating the following differences:

  • Objects focus on conceptual entities whereas components are based on more physical things.
  • Objects and components are both language dependent and separate interface from implementation, but components depend on context too.
  • Components are more pragmatic and impose a less rigorous discipline on the developer.

His most controversial point was that, while supporting encapsulation, components failed to support inheritance and other forms of polymorphism. Several people objected that he seemed to have a completely different idea of what a component was from everyone else in the circle and opined that "if we forget polymorphism, we’ve learnt nothing from OO". I think Peter’s most interesting statement was that "the larger the component, the less likely [that] it will be an ideal match to a requirement", leading to the need to bootstrap larger components. Clearly the discussion reflected some industry confusion over terminology, with large things like Word and Excel (which aren’t polymorphic) being offered as examples of components while other people think of things such as EJB or COM+ finer grained components.

The audience was asked, on a show of hands, how many were clear about the distinction between objects and components when they entered the room. Nine hands went up. At the end of the session only five people answered this question positively; which clearly indicates a problem in the face of what was actually a very informed debate. I am convinced that components are (as Paul Allen and Stuart Frost put it in their book [1998]) merely "a new way of presenting objects to the market".

Andrew Watson enumerated a number of dichotomies that he thought would discriminate the concepts:

  • Objects were typically smaller than components
  • Objects worked within the boundaries of one programming language rather than several
  • Components could include their own metadata while objects relied on separate metadata
  • Components replaced traditional programming with the idea of assembly
  • Objects stated what they provided in their specification whereas components also had to specified the services that they required in order to work

This last point raises an interesting question for me. Writing about object-oriented analysis and business process modelling I had always been forced to assume that objects had to include a ‘requires’ segment in their specification. This is at the root of the notion of collaboration in RDD and is represented in SOMA by object’s message/server pairs (usage relationships). The fact that object-oriented programming languages do not support this is possibly one of the reasons that most methods and notations like UML fail to offer a distinguished ‘usage’ association. So, Andrew’s comparison is clearly aimed at distinguishing components from the common, language level notion of objects, rather than a more rounded notion of an object suitable for modelling business objects (which the OMG task force is now referring to as components as it happens). From that point of view I wonder if we could argue that a component is what an object should have been all along if we had defined it correctly.

Alan Wills pointed out that all software is very hard to change and that we expect components to at least address this problem. Alan O’Callaghan pointed out, to little disagreement that much discussion of components is vendor led. He argued that components were (tautologically) things that could be composed and defined a component as a software entity playing the role of a component in a composition. He then argued that this is different from saying they are things that could be simply composed. Lego bricks, screws and house bricks were not components (as is often suggested) when they are standing alone, but only when they are in some larger composition. Once in a composition they are as much a component as any other element that was not pre-built. The difference between them and the other purpose-built components is that they have a special quality of being usable, potentially, in more than one composition. Thus composition was much more important than inheritance and that this could not solve the software crisis: nothing fundamental has changed! Interestingly, this theme was echoed by Jim Coplien in a later OT99 goldfish bowl, where he argued that in comparison to hardware engineering, which was continually revolutionizing its product according to Moore’s law, there had been no fundamental improvement in software engineering since 1956 (the invention of high level languages). Relative to most other fields, our industry was actually dysfunctional. Also, he said, no extant OO language implements the original vision of object-orientation. Alan also said that we needed to focus on qualities that make components usable in potentially more than one composition. Successful CBD will require a heightened focus on software architecture and an enhanced emphasis on object modelling (echoing the argument that I made above for embedding usage relationships in the interface).

The question Alan then posed, in face of the vendor-led hype about "software's industrial revolution", was what was the software crisis and how did these new components solve it? The essence of the software crisis was the complex nature of the problem for which software is being used to provide solutions. Fred Brooks in 1987 clearly differentiated between this (‘the conceptual essence’) and other problems of software development (i.e. representation) which he considered to be ‘accidental’ in the Aristotelian sense. Essential complexity hits us in the face in terms of the composition (the whole) not in its parts, and he suggested that the ‘new’ idea of components did not solve the software crisis and bring about the software industrial revolution for the simple reason that, in and of themselves, they did not address this conceptual essence. Not a single one of the issues that bedevilled software reuse through OO development was solved by components; real advances in that direction would come through a focus on object modelling and software architecture. This would become clearer once the Y2K and EMU-conversion issues were out of the way. Big corporations' use of ERP modules to solve these twin problems at one fell swoop in certain constrained areas have temporarily inflated the market for pre-built solutions. The ERP vendors themselves know this to be true, because they are tring to find ways to ‘componentize’ their products. And we are getting e-mails from their consultants asking about modelling and architecture...

Charles Weir asked "what are you buying when you buy a component?" and answered his rhetorical question with "something tested". Surely that was at least a small step forward. Furthermore that use of standard components helps organizations to enforce architectural choice: another mitigator of chaos.

Kevlin Henney said that the focus of component based develoment was on deployment. Given that a component in the context of this discussion is not synonymous with a single object (or even, more accurately, class), this does not mean that we have a contradiction with respect to analysis of key business issues. These are more the concern of earlier parts of the lifecycle, and their realization is in the more traditional realm of OO. As the lifecycle progresses, one will turn naturally more toward matters of deployment architecture, and hence the packaging of units of development: components make great packaging for objects. CBD and OO share a common set of principles, but one is talking about the logical concepts within a system and the other about the physical shape of a system. He emphasised that although we need to consider establishing a stable baseline architecture early (i.e. prototypes and proof of concepts explored iteratively from the start as opposed to ‘waterfalling it’), he believed that the idea of trying to ‘analyse components’ from the word go is often misguided. There seems to be a bandwagon/trend of people rushing into analysing 'components', and this means that either they are just doing traditional OO (but with a global replacement of ‘component’ for ‘object’), or that they are clueless about the problem they are trying to solve but have figured out mysteriously/magically/not-at-all what they are going to ship. This raises the issue of how problems are to be decomposed. If components shift the emphasis from earlier to later in the life cycle, this means that changes ought to be easier. Of course, there is an implicit contradiction here. On the one hand components emphasize the need for architecture whilst on the other they could be used as an excuse to defer analysis of key business issues, which I think is a great danger. On the other hand, it could be argued that this isn't so much a contradiction, as a sign that deployment architecture is not equivalent to understanding of key business issues.

Basing a method around identifying components at analysis time seems like the end of Restaurant at the End of the Universe where the Golgafrinchans are trying to reinvent the wheel, but have spent all their time worrying about what colour it will be. Focusing on components alone is like the sound of one hand clapping, but it doesn't seem to have stopped hype merchants touting them as the answer to everything, rejecting all that has gone before. This relates to another point made by Kevlin, which was to distinguish between conventional software use of the term component – to mean any part of a program, including functions, classes, etc – and the CBD usage – which he defined as ‘a unit of executable deployment that plays a role in a composition’, having adapted/evolved/extended his usual definition in the light of what Alan O'C said about composition. The distinction he drew was between "component" with a 'c' – the general meaning of the word – and "Component" with a 'C' – the CBD specialization of it.

John Daniels was irritated that everyone seemed to have a different definition of components and pointed out that only individual vendors were clear on their own definitions, which of course were all different. The issue of standards therefore arises so that at least the vendors could converge on agreement.

Andrew Watson asked Alan O’Callaghan whether components represented any advance at all. He replied affirmatively, because there is clearly a gain in productivity and cost-saving etc., if you can buy something rather than build it. That, exactly and precisely is the gain you get. At most, you deliver more quickly today than you did yesterday (later John Daniels suggested even this gain is centred almost exclusively in middleware and it is easy to agree with him). Earlier delivery is a requirement that is real, and so gains in this direction are extremely valuable in a competitive world. But who believes the industrial revolution was solely about early delivery? And who believes that early delivery solves the software crisis? In terms of dealing with the software crisis, Alan asked what the bit of magic is in the black box (the component) that wasn't there when I handcrafted solutions using objects? Without modelling the problem space, and specifying a software architecture that has some strong correspondence to the problem space, how do I even know which components to buy ?

As the discussion broadened, it was thought that concepts should be maintained throughout the life cycle, so that there was better seamlessness. Phil Boardman raised the oft used hardware simile, harking back perhaps to Brad Cox’s coinage (or was it Tom Love’s?): the software IC. Were components the fulfilment of this promise? Eoin Woods asked what were the steps that took one from a concept to the corresponding component(s). Alan Wills saw components as mainly a middle-tier idea. Francis Glasborrow wanted to emphasize replaceability. Andy Carmichael repeated the view that COMPONENTS was a "vendor-led word to help sell products". John Daniels raised another issue that merited further discussion; that components meant a shift to instance level as opposed to class level reuse. This was not explored in any detail, but it is obviously an important question that raises inter alia the debate about the rôle and nature of class methods in object technology. Alan Wills thought that fine-grained reuse had failed. He also opined that components – when viewed as executables rather than as business objects (back to the middle tier view!) – enforced a useful discipline during the process of system modification. Jukka Tamminen made the important point that a system is more than the sum of its components and that we viewed them in isolation at our peril. Frameworks of course emphasize this view.

Richard Drake introduced a new theme, that of the open source movement. He also exclaimed: "I’ve been here before". Returning, I think, to the essence of John Daniels intervention, he wanted us to consider the value of source code reuse. However, this proved to be an unpopular view and there was still no deep discussion of the issue. More controversially still he thought that a component was something that could be used by a user via a scripting language.

Alan O’Callaghan made the last contribution, pointing out that the discussion was not a new one and that it had been revived by vendors' self-interest. John Udell pronounced objects as ‘dead’ and componentware as the future in a Byte feature splashed over its front cover (May 1994). That was three years before OT went mainstream by most people's reckoning. The touted technologies were Microsoft's VBX controls, OLE 2.0/COM, DEC's ObjectBroker, IBM's SOM, Sun's OpenStep, Novell's Appware, and OpenDoc. None of these survives today in its 1994 form, and a few have disappeared altogether, while OT has gained strength.

As the discussion ran out of time there was general agreement on the view that the whole idea of components was no use without solid architecture. A key dichotomy asked whether it was all about managing complexity or about issues of delivery and maintenance. There was no consensus either on whether components were to be small or large. It was no surprise to me that the original question posed had not been answered and that uncertainty had actually increased despite the relative profundity of the discussion and high quality of the contributions to it. Perhaps this means that not only are we, as an industry, uncertain about what a component is; perhaps we don’t even have a good, commonly understood notion of object.

complete solutions for components
(consultancy, courses, workshops, mentoring, seminars, development)

email us  or  tel  UK:  01625 850 839  international:  +44 1625 850 839