I take it as a chellenge to prove that the problem of achieving a symbiosis of hybrid components is directly related to the problems addressed by object-oriented technology.


Web Applications

Component-technology

Heterogeneous systems


slide: Heterogeneous systems

Let us first observe that object orientation is about program organization, and not about programming per se. As we will do in the remainder of the book, to master this art we need to acquire expertise in idioms, patterns, modeling, validation, programming language constructs (including constructs for distribution and concurrency), programming techniques, theoretical foundations, libraries and system development. Our discussion of distribution will indicate that (distributed) object-oriented technology intrinsically supports the development of heterogeneous systems.

Moreover, our repertoire of idioms and patterns for example wrapping (employing encapsulation and refinement) provides us with the means to realize heterogeneous systems as the integration of multiple (hybrid) components in a more or less transparent manner. Wrapping allows us to incorporate old (procedural) code by defining a clean object interface. The need for distribution is obvious. Logical distribution to ensure well-engineered systems, and physical distribution (primarily) to deploy geopgraphically distributed resources.

As a remark. the motivation for employing wrapping as a technique for reuse may be that the code involved cannot be rewritten, due to a lack of resources or expertise. Wrapping, despite its ad hoc nature, may in practice be a good substitute for (object-oriented) redesign.

A intrigueing trend that I wish to mention is the development of embeddable interpreters, and the combinations of interpreted languages (such as Tcl, Perl and prolog) with system implementation languages (such as C, C++, and java). Moreover, in many cases for example widget bindings (to Tk widgets, Athena or Motif widgets) are offered in both languages. A drawback is that these binding have for the greatest part only been realized on the level of functions and procedures and not on the level of objects. The Java native runtime interface is a step in the right direction, but we will explore how to cross the language boundary in a way that allows us to have a close coupling between the objects living at either side of the boundary. providing a mapping between object interfaces instead of single functions.

Let us briefly reflect on the status of object-orientation. Is it worth investing in, and where will it lead us? My opinion is, simply, object orientation is here to stay. Object orientation is commercially viable, as testified in  [Harmon93]. Moreover, it is the method of choice for every conceivable application domain.

From a somewhat different perspective we may say that object-orientation allows us to maintain a high level of buzzword compliancy. But the truth of the matter is that we may actually realize much of what in the past had to be considered as pure project speak.


Project speak

terminology



slide: Terminology -- project speak

The phrase open is mostly used to indicate that the result will not be a closed system, but may be extended to include extraneous functionality. By their very nature, objects are extensible by means of refinement by inheritance (provided they are well-designed).

The phrase heterogeneous is often meant to indicate that the result is dependent on extraneous components, that will be obtained from some external source. Given the complexity of many systems (including information systems, management support systems or systems for scientific visualization), this is only natural. The difference with earlier times lies primarily in the way in which such extraneous components are being (re)used. Object-oriented technology in principle makes it possible to reuse components in a clean way, without requiring access to the source code.

The phrase distributed is often motivated by the wish to support the interaction of geographically distinct components or to achieve speed-up by means of parallel/distributed processing. However, parallel/distributed programming is intrinsically difficult. Distribution seems to be an area in which the technology has not (yet) outgrown the level of systems programming. Also here, object orientation appears to be gaining ground.

The phrase object orientation itself has in the past often been abused. See  [Ki89] and  [St88]. However, now the technology is maturing, the standards with respect to what may be called object-oriented are becoming more solid, and object orientation is increasingly recognized as being valuable both in modeling and programming, and not merely as a trend.

Finally, the phrase intelligent, encountered in a variety of situations, may be taken to mean either adaptable, tunable to user needs, augmented with reasoning capabilities, or simply superior. In a more neutral way, it may be taken to mean the incorporation of logic-based, declarative (programming) formalisms to specify the functionality of a system in a knowledge-based manner.

On the one hand, there lies a challenge to incorporate (and actually employ) object-oriented technology in, for example, expert systems, but also hypermedia (Web) applications and (intelligent) information systems. It is my personal belief that logic-based programming and specification techniques may be fruitfully applied in object-oriented system development.

That was, so to speak, the good news. And now for the bad news. The bad news, as we may for example find in  [Surviving] that object-orientation is hard to learn. Learning takes time, and is expensive. This might be a mojor stumbling block in adopting object-technology. Learning just enough to get ahead is, as experience has proved, not enough for succesfully completing a project. To get the real benefits an investment in learning is needed. One must learn the terminology, the concepts, how to approach a problem, examples of best practice and the limitations of the technology. As a group, one must learn how to communicate with others, how to explain structural and behavioral properties of components and systems of components, and how to decide what is best under constraints of time and resources.

One potential danger that haunts the field of object orientation is the diversification of programming languages, programming techniques, analysis and design methods and development frameworks. incompatible compilers. The only way to resolve the problems of proliferation is by consensus and to some extent by standardization.

Consensus and standardization involve not the adherence to a single language reference manual but more importantly an agreement on the terminology employed. and the adoption of appropriate conventions concerning issues of design and the utilization of object-oriented techniques. This book has been written from the conviction that an understanding of the theoretical foundations of object-oriented programming is a prerequisite to the development of a consensus concerning these issues, if not interesting for its own sake.