¶ … object-oriented (OO) 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 complimentary extension to OO to overcome its primary disadvantages. Given the differences between objects and components, this paper makes recommendations for developing systems using both constructs. Finally, the future of objects and components is discussed. Assembly languages started the abstraction process by coding the binary-based machine code, or pulse train of successive 0s and 1s, into assemblies representing particular machine code sequences (Hoagland). Next, higher level languages made coding closer to human readable. The language and its compilers were coordinated such that the output would give a computational valid result. OO programming raised the level of abstraction in programming even further. OO programming is a programming language model organized around "objects" rather than "actions" and data rather than logic.

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 defined as:

Complex objects are built from simpler ones by applying constructors to them. The simplest objects are objects such as integers, characters, byte strings of any length, booleans and floats (one might add other atomic types). There are various complex object constructors: tuples, sets, bags, lists, and arrays are examples

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

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

A type, in an object-oriented system, summarizes the common features of a set of objects with the same characteristics. 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 the class. The user can manipulate the warehouse by applying operations on all elements of the class.

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

Overriding is the redefinition of the implementation of the operation for each of the types according to the type. The system cannot bind operation names to programs at compile time. Therefore, 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, that supply to applications basic system functionality, such as visual interface elements and stacks (Hoagland).

However, OO programming has only been a modest success to date for a variety of reasons. For one, skills are not available in the typical IT organization to leverage this complex technology (Hurwitz, 1998). For example, inheritance requires that developers know exactly what they are inheriting. Thus, it is very easy for the developer to make a mistake. The developer is expected to select from libraries of hundreds or thousands of existing objects to create complex applications. This process is very confusing. It can be difficult to find the right object for the right task and to distinguish between objects that perform similar functions. And, the full benefits of OO programming were never fully realized, partly because implementation inheritance defeated true encapsulation (Hoagland). Also, OO programming has never fully fulfilled its promise of much 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. It success in the market has been largely due to the advent of the distributed era of computing with its demand for truly encapsulated code to be delivered on a much shorter time frame.

Component software represents the extension of OO programming as described below (Hoagland):

Object technology has brought to light -- and tried to...

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:

have encapsulation properties are accessed via well-defined interfaces are considered to improve the reuse of software are considered to alleviate the software evolution phase are thought of being natural abstractions of real-world entities allow a real-world entity to be modelled/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, 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. However, at runtime, a single instance of a component is instantiated at a nearby or far away 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. 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).

There are also other differences between components and objects. One is the division of labor (Hurwitz, 1998). Components create two classes of developers. The first group of developers are highly skilled developers who can use all the power of objects to create fine-grained objects that they then string together to create large-grained business-oriented components. The second group is the traditional corporate developers who do not know how to program in complex object-oriented languages. These developers use components created by the more skilled developers. The corporate programmer is not allowed 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 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. 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 on a consistent basis in a new applications environment. 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 to be used 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 may have a component called "cost to produce yellow napkins." Thus, it is very easy to determine which service each of these components is intended to provide.

One of the big advances of component technology is that it has extended the scope of object design outside the…