Component oriented software development

What do we mean by component-oriented (application) development (COD)? What linguistic ingredients are necessary to realize COD? In this note we are only concerned with a linguistic construct that mechanizes the composition of components.

Generally, COD connotes the capability of shelving (fully) compiled program modules that can be used directly in composing larger programs. The criterion is the ability to pick a component off the shelf and use it without any form of processing.

In practical terms, the criterion stipulates that, in order to use a component we should only need an include file for its definition. It further emphasizes that we should not have to change the include file in any way.

In the universe of software, a shelf is a directory of files somewhere on the Internet. COD is not concerned with operational details at run-time. The program we compose may grab its components from around the world as it proceeds, or the components may simply reside on the same node that is hosting the program.

Specifically, a component is a unit of abstraction, and not a bundle of classes. The latter may be more accurately referred to as a package or library. A component, however, may be represented via the class mechanism in a header file. Due to the difficulty of presenting code in bloggers, the linguistic nature of an apparatus that facilitates the deployment of the compositional property is illustrated in Z++ Components.

In Z++ programming language, one composes a program from components through the representing classes of those components. The user program does not have any knowledge of the implementations of the entry points comprising the boundary of a component. Thus, a Z++ component is a unit of abstraction regardless of however large and complex it may be.