Object-Oriented vs Component-Based Software Development
This paper examines the relationship between object-oriented (OO) programming and component-based software development, tracing the abstraction process from assembly language through high-level languages to OO programming. It outlines the eight core features of OO systems as defined in the object-oriented database system manifesto and discusses why OO programming achieved only modest success, particularly around issues of inheritance complexity and limited code reuse. The paper then explains how component-based development emerged as a complementary extension to OO, detailing the key differences between objects and components in terms of abstraction level, runtime behavior, division of labor, and business focus. Recommendations are made for combining both paradigms, and the paper concludes by addressing emerging threats to object and component technology from Web-based and mobile computing environments.
- Introduction and the Evolution of Abstraction: From assembly language to OO programming's emergence
- Core Features of Object-Oriented Programming: Eight defining features of OO systems explained
- Limitations of Object-Oriented Programming: Why OO achieved only modest real-world success
- From Objects to Components: Key Differences: Abstraction, runtime, labor, and business focus compared
- Recommendations for Combining Objects and Components: How to use both paradigms together effectively
- Future Challenges for Object and Component Technology: Web and mobile computing as emerging threats
✍️ How to write this paper — guide, tools & examples ▾
What makes this paper effective
- The paper builds its argument logically, moving from historical context (assembly language, high-level languages) through OO programming and then to component-based development, creating a clear narrative arc that is easy for readers to follow.
- It grounds abstract technical concepts in concrete examples, such as the "30-year mortgage calculations" component, making the distinction between technically focused objects and business-focused components immediately understandable.
- The paper balances a structured definition of OO features (using the eight-point manifesto) with a nuanced critique of its limitations, which strengthens its argument for component-based development as a complementary — rather than replacement — paradigm.
Key academic technique demonstrated
The paper demonstrates effective use of comparative analysis. Rather than simply advocating for one paradigm over the other, it systematically identifies the dimensions along which objects and components differ — abstraction level, runtime instantiation, division of labor, and business orientation — while also acknowledging their shared properties. This balanced approach allows the author to make a reasoned, evidence-based recommendation rather than a one-sided assertion.
Structure breakdown
The paper opens with historical context on abstraction and OO programming, defines OO features using a cited academic manifesto, critiques OO's limitations, introduces component-based development as an extension, compares the two paradigms across multiple dimensions, offers practical recommendations for combining them, and closes with a forward-looking discussion of threats from Web and mobile computing. This six-part structure moves cleanly from definition to critique to synthesis to future outlook.
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).
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: http://www.acm.org/sigplan/oopsla/oopsla99/2_ap/tech/2d1a_arecmp.html
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
Create your account
Always verify citation format against your institution’s current style guide requirements.