CONTEXT-ORIENTED PROGRAMMING

Context-oriented programming (COP) introduces one more notion to reason about the structure of software systems: a context (an environment) is a set of entities bound with a system of relations. This view is applicable where the object-oriented one is inadequate. Implementation of COP requires the same techniques as OOP: COP and OOP are different things assembled from the same components. COP allows things that OOP cannot do, for example, COP enables us to use late binding for elementary data that are not OOP objects. 1. The purpose of the work The key element of software activities (like designing, writing, debugging, reading and modifying programs) is reasoning. We do not give a definition for reasoning, but we assume that the use of a small number of adequate concepts facilitates reasoning—that is, if the concepts in use are adequate and expressive, if no auxiliary concepts are required, it is easier to reason about programs. The purpose of this work is to extend the set of notions, which may be used to reason about the problem to be solved and the structure of the corresponding software system. Along with the notion of a context, an approach to problem decomposition, and a programming technique appear. 2. The method of COP 2.1. Quick introduction An environment (a context) expresses the idea of a system of relations (where "relation" is used in its everyday meaning, a connexion between things). The phrase "system of relations" implies that there are some entities, upon which relations are established. The key point in COP is that to use the relations, we do not need to know details about the entities. This is good, but how can we use the relations? In principle, different approaches are possible. The simplest way is to implement a set of functions, which imply that the data elements to be processed are bound with these relations. (Indeed, using these functions, we use knowledge of that the data elements are related, otherwise it would be incorect to use the functions). The next step is to introduce polymorphism. This may be done via tables of pointers to functions, that is, virtual method tables (VMT, where "method" is understood as "member function"). Contexts are implemented as VMT's, and these VMT's are not bound to data. So, from the implementation point of view, there are interchangeable sets of functions, allowing us to work with different (but somehow similar) sets of objects; the objects in a set do not necessarily form a datastructure, and may have different lifetimes. It should be also noted that COP introduces two levels at which we can work with contexts. At the level of implementation, we know all details about related entities that constitute the context. At the level of use, we do not have full access to the entities; we can use only a set of functions allowing us to work with the entities, but this should be enough to accomplish our tasks. In exchange, this restricted access allows us to work in different contexts (of the same "class") in a uniform way.