Object-Oriented vs Component-Based Software Development

Introduction and the Evolution of Abstraction

This paper examines the relationship between object-oriented (OO) programming and component-based development. It begins by describing the evolution of the abstraction process and the emergence of OO programming. Next, the limitations of OO programming are discussed along with an explanation of how component-based development was born to serve as a complementary extension to OO in order to overcome its primary disadvantages. Given the differences between objects and components, this paper also makes recommendations for developing systems using both constructs. Finally, the future of objects and components is discussed.

Assembly languages started the abstraction process by encoding binary-based machine code — the pulse train of successive 0s and 1s — into assemblies representing particular machine code sequences (Hoagland). Higher-level languages then made coding closer to human-readable form, with language compilers coordinated to produce computationally valid results. OO programming raised the level of abstraction even further. OO programming is a programming language model organized around "objects" rather than "actions," and around data rather than logic.

Core Features of Object-Oriented Programming

According to object-oriented experts Atkinson, Altair, DeWitt, Dittrich, Maier, and Zdonik (1989), an object-oriented system has eight main features: complex objects, object identity, encapsulation, types and classes, inheritance, overriding combined with late binding, extensibility, and computational completeness. These are defined as follows:

Complex objects are built from simpler ones by applying constructors to them. The simplest objects include integers, characters, byte strings of any length, booleans, and floats. There are various complex object constructors: tuples, sets, bags, lists, and arrays are examples.

Object identity means an object has an existence that is independent of its value.

Encapsulation satisfies the need to cleanly distinguish between the specification and the implementation of an operation, as well as the need for modularity.

Types and classes: A type, in an object-oriented system, summarizes the common features of a set of objects with the same characteristics. A class is more of a run-time notion. It contains two aspects: an object factory, which can be used to create new objects, and an object warehouse. The object warehouse means that attached to the class is the set of objects that are instances of that class. The user can manipulate the warehouse by applying operations on all elements of the class.

Inheritance is a powerful modeling tool that provides a concise and precise description of the world, and it helps in factoring out shared specifications and implementations in applications.

Overriding combined with late binding: Overriding is the redefinition of the implementation of an operation for each type according to that type. Because the system cannot bind operation names to programs at compile time, operation names must be resolved at run-time. This delayed translation is called late binding.

Extensibility means that one can define new types and there is no distinction in usage between system-defined and user-defined types.

Computational completeness means that one can express any computable function using the data modeling language of the database system.

One of the largest contributions of OO programming has been the success of developmental frameworks — the expression of operational polymorphism in sets of system classes grouped into collections called libraries, such as Microsoft Foundation Classes, which supply applications with basic system functionality including visual interface elements and stacks (Hoagland).

Limitations of Object-Oriented Programming

However, OO programming has achieved only modest success to date, for a variety of reasons. First, the skills required to leverage this complex technology are not widely available in the typical IT organization (Hurwitz, 1998). For example, inheritance requires that developers know exactly what they are inheriting, making it very easy to introduce mistakes. Developers are expected to select from libraries of hundreds or thousands of existing objects to create complex applications — a process that is often confusing. It can be difficult to find the right object for the right task and to distinguish between objects that perform similar functions.

Furthermore, the full benefits of OO programming were never fully realized, partly because implementation inheritance defeated true encapsulation (Hoagland). OO programming has also never fully fulfilled its promise of significantly greater code reuse. The high cost of software creation and the failure to follow good coding practices contributed to the rise of software components and component-based development. OO's success in the market has been largely driven by the advent of the distributed era of computing, with its demand for truly encapsulated code delivered on much shorter time frames.

From Objects to Components: Key Differences

Component software represents an extension of OO programming. As Hoagland explains:

"Object technology has brought to light — and tried to free us from — the limitations of the traditional view of a program as an executable that does one thing. Beyond this simple view, object technology introduces the notion of class, providing a number of well-specified operations (commands and queries) on a certain data abstraction. We can take a program and make it into a component, but unless it is a trivial one-input/one-output program, we will need to 'componentize' it: wrap it into a hull, with a set of openings providing to the rest of the world the set of operations that we expect the program to perform for us on request."

Thus, OO programming involves constructing a new system in terms of interacting, distinct units of information and services called objects, while component-based programming involves constructing new systems from already existing, service-providing components (Petre, 2000). Both components and objects share several properties: they have encapsulation properties; are accessed via well-defined interfaces; are considered to improve software reuse; are considered to alleviate the software evolution phase; are thought of as natural abstractions of real-world entities; and allow real-world entities to be modeled and implemented.

During development, a component translates more or less to a collection of objects (Henderson-Sellers, Pradhan, Szyperski, Taivalsaari, and Wills). A developer is able to use the same concepts of objects, object relationships, and object stereotypes, and apply them successfully to a "group of objects," or a component. Patterns that can be applied to create components can also be used to create a group of objects. Thus, during development, components and objects are not very different, except for the fact that a component is a collection of objects.

However, at runtime, a single instance of a component is instantiated at a nearby or remote server to provide all the functionality expected of the component through its interface. Objects, on the other hand, can be instantiated multiple times and may reside on one or more machines. There is therefore a distinct difference between 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.

There are also other important differences between components and objects. One is the division of labor (Hurwitz, 1998). Components create two classes of developers. The first group consists of highly skilled developers who use the full power of objects to create fine-grained objects, which they then string together to create large-grained, business-oriented components. The second group consists of traditional corporate developers who do not know how to program in complex object-oriented languages. These developers use components created by the more skilled group. The corporate programmer is not permitted to change the component's content. Thus, a coarse-grained component does not allow inheritance to be applied, which protects the integrity of the component and helps prevent mistakes.

Components also offer a higher level of abstraction than objects (Henderson-Sellers, Pradhan, Szyperski, Taivalsaari, and Wills). Objects form abstractions over identifiable parts of a state space: they have a unique identity and encapsulate the variables and operations that define the abstracted part of the state space, meaning no two objects occupy the same partition of the universal state space. Components, by contrast, 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 — preferably with dependencies that are configurable. Components are coarse-grained pieces of application code with well-defined APIs (Hurwitz, 1998). With components, encapsulation becomes one of the foremost techniques for leveraging existing code so that it can be reused consistently in new application environments. In most "pure" object-oriented systems, very little use is made of existing code from pre-built older systems. In the component model, encapsulation is a fundamental building block; organizations can select key pieces of logic from an older system and encapsulate them as business objects or components for use within existing systems.

Another key difference between objects and components is focus (Hurwitz, 1998). While objects tend to be focused on the technical functions they provide, coarse-grained components are focused on the business task. For example, a financial organization might implement a component called "30-year mortgage calculations," and a manufacturing company might have a component called "cost to produce yellow napkins." It is therefore very easy to determine which service each component is intended to provide.

One of the major advances of component technology is that it has extended the scope of object design beyond the range of a single execution space; object designs can also cross language boundaries (Henderson-Sellers, Pradhan, Szyperski, Taivalsaari, and Wills). Separation of concerns is a fundamental design principle of both objects and components: they can both encapsulate state with operations, and the technique of assigning responsibilities and collaborations works for both. But unlike an object, a component is part of a kit that defines a common set of protocols among its members. The developer assembles end-products by selecting components from the kit and plugging them together without having to be concerned with how the components and their plug points work internally. Pluggability is an object-oriented design principle that is strongly emphasized in component-based development, and the technology of interface definitions supports it well.

Bibliography

Atkinson, M., Altair, F., DeWitt, D., Kittrich, K., Maier, D., & Zdonik, S. (1989). The object-oriented database system manifesto. Retrieved November 28, 2003, from University School of Computer Science Web site:

Henderson-Sellers, B., Pradhan, R., Szyperski, C., Taivalsaari, A., & Wills, A. Are components objects? Retrieved November 28, 2003, from Association for Computing Machinery Web site:

Hoagland, J. From object oriented to component-based software. Components Online. Retrieved November 28, 2003, from Components Online Web site:

Hurwitz, J. (1998, May). Component directions. DBMS Magazine. Retrieved November 28, 2003, from DBMS Magazine Web site:

Petre. (2000, October). Components vs. objects. Retrieved November 28, 2003, from