So the component-orientation mixes a set of features of its predecessor models. Understanding it is simpler while thinking of the visual component, that is an application[4] which not being deployed into an executable or bytecode but otherwise turned to be linked by an icon inside another application, icon when one clicks on it implements certain tasks.[5] Then this concepts can be extended to non-visual components.[6]
In database activities, the component, visual or not, is an aggregate of classes, in the sense of OO, that can be linked to other ones by adapters.[7]
As after the OO model conception data and code programming code are mixed in a cohesive body,[8] there are some difficulties in conceiving where the CODB and CO programming are separate one from the other. Although this enigma is important in conceptual epistemological area, in practical data processing there isn't so importance in this question because of usage of mapping models to large scale used software, like the mappings called ORDBMS and CRDB (component-relational database), in which the separation of data and code are still well defined.[9]
Implementation
In programming activity, the CO is often taken place with large-scale used OO languages (like C++, Java) with mapping adaptation. In designing the paradigm is supported by UML. In data modeling, data administration and database administration, the mapping adaptation is alike the ORDBMS paradigm. The adapted paradigm to component-based models is known as component-relational database (CRDB).[10]
Advantages
The main advantage of the component-oriented thinking is the optimization of reusability of work. The CO paradigm allows the use of ready to use applications as modules to new and bigger projects.[5]
The notions of OO such as encapsulation, inheritance and polymorphism do not necessarily lead to the idea of reusing applications as modules of new works.[citation needed] The CO thinking also assures that components are fully tested, as a real application, and thus there is in this model the paroxism of reuse,[11] as well as the feature of understandability to end users, as corollary of the app->comp way of realizing the IT works.[clarification needed]
Even using the same software that are present in OO paradigm, there are many specific consequences in the world of data-oriented activities. In analogous way, whole models composed of classes can be treated as a part (component) of a new more comprehensive model.[citation needed]
Cho, Eun-Sun; Han, Sang-Yong; Kim, Hyoung-Joo. A New Data Abstraction Layer Required For OODBMS, Proceedings of 1997 International Database engineering and Applications Symposium (IDEAS’97).
Clemente, Pedro J.; Hernandez, Juan. Aspect Component Based Software Engineering, Proceedings of the Second AOSD Workshop on Aspects, Components, and Patterns for Infrastructure Software (ACP4IS), March 2003.
Clements, Paul. From subroutines to subsystems: Component-Based Software Development. Brown, Allen. Component-Based Software Engineering: Selected Papers from Software Institute, 1996.
Erich Gamma, Erich; Helm, Richerd; Johnson, Ralph; Vilssides, John. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995, ISBN0201633612.
Garcia-Molina, Hector; Ulman, Jeffrey D.; Widom, Jennifer, Database Systems – A complete book. Prentice Hall, 2002, ISBN0131873253.
Pfister, C.;Szyperski, C.. Why Objects Are Not Enough, Proceedings of Component Users Conference, Munich, Germany, 1996.
Rotaru, Octavian Paul;Dobre, Marian;Petrescu, Mircea. Integrity and Consistency Aspects in Component-Oriented Databases, Proceedings of the International Symposium on Innovation in Information.
Stroustrup, Bjarne. Why C++ is not just an Object-Oriented Programming Language, Addendum to OOPSLA95 Proceedings, ACM OOPS Messenger, October 1995.
