Concept-Oriented Programming

Concept-Oriented Programming

Alexandr Savinov (University of Bonn, Germany)
DOI: 10.4018/978-1-60566-026-4.ch109
OnDemand PDF Download:
$37.50

Abstract

In the concept-oriented programming (CoP) (Savinov, 2005, 2007), the main idea is common to many other approaches and consists in raising the abstraction level of programming by introducing new language constructs and mechanisms. The distinguishing feature of CoP is that it aims at automating the way objects are represented and accessed (ORA). More specifically, one of the main concerns in CoP is modeling the format of object references and the procedures executed during object access. For example, if we need to retrieve the current balance stored in a bank account object then we make the following simple method call: account.getBalance(). In object-oriented programming (OOP), it results in an instantaneous execution of the target method because this variable contains a primitive reference which is supposed to provide direct access to the represented object. In CoP, it is not so and everything depends on the format of the reference used to represent this account object. References in CoP have an arbitrary custom format defined by the programmer and hence objects are represented indirectly using abstract identifiers from a virtual address space. In this case, the real procedure executed during access depends on what is stored in the variable account. In particular, it may well happen that the account object is stored on a remote computer in another organization. Then, its reference can be rather complex and include such fields as bankName and accNo (Figure 1). Object access to such an indirectly represented account will involve many intermediate operations like security checks, transaction management, network packet transfer and operations with persistent storage. However, all these intermediate actions will be executed behind the scenes so that we have the illusion of instantaneous action. Then the programmer is still able to use the target objects as if they were local directly accessible objects, at the same time having a possibility to inject any intermediate code responsible for object representation and access (ORA). References in CoP are as important as objects because both have arbitrary structure and behavior associated with them. If OOP deals with objects then CoP deals with both objects and references. The main role of references consists in representing objects, that is, they contain some data that makes it possible to access the object. Thus, references are intermediate elements which are activated each time the represented object is about to be accessed. For example, each time we read or write a field, or call a method, the object reference intercepts these requests and injects its own actions. Thus, any object access can trigger a rather complex sequence of intermediate actions which are executed behind the scenes. In large programs this hidden functionality associated with references can account for a great deal or even most of the overall complexity. The main task of CoP in this sense consists in providing adequate means for effectively describing this type of hidden intermediate functionality which has a cross-cutting nature. OOP does not provide any facilities for describing custom references and all objects are represented and accessed in one and the same way. CoP fills this gap and allows the programmer to effectively separate both concerns (Dijkstra, 1976): explicitly used business logic of objects and intermediate functions executed implicitly during object access.
Chapter Preview
Top

Introduction

In the concept-oriented programming (CoP) (Savinov, 2005, 2007), the main idea is common to many other approaches and consists in raising the abstraction level of programming by introducing new language constructs and mechanisms. The distinguishing feature of CoP is that it aims at automating the way objects are represented and accessed (ORA). More specifically, one of the main concerns in CoP is modeling the format of object references and the procedures executed during object access.

For example, if we need to retrieve the current balance stored in a bank account object then we make the following simple method call: account.getBalance(). In object-oriented programming (OOP), it results in an instantaneous execution of the target method because this variable contains a primitive reference which is supposed to provide direct access to the represented object. In CoP, it is not so and everything depends on the format of the reference used to represent this account object. References in CoP have an arbitrary custom format defined by the programmer and hence objects are represented indirectly using abstract identifiers from a virtual address space. In this case, the real procedure executed during access depends on what is stored in the variable account. In particular, it may well happen that the account object is stored on a remote computer in another organization. Then, its reference can be rather complex and include such fields as bankName and accNo (Figure 1). Object access to such an indirectly represented account will involve many intermediate operations like security checks, transaction management, network packet transfer and operations with persistent storage. However, all these intermediate actions will be executed behind the scenes so that we have the illusion of instantaneous action. Then the programmer is still able to use the target objects as if they were local directly accessible objects, at the same time having a possibility to inject any intermediate code responsible for object representation and access (ORA).

Figure 1.

Indirect method call via custom references and intermediate operations

References in CoP are as important as objects because both have arbitrary structure and behavior associated with them. If OOP deals with objects then CoP deals with both objects and references. The main role of references consists in representing objects, that is, they contain some data that makes it possible to access the object. Thus, references are intermediate elements which are activated each time the represented object is about to be accessed. For example, each time we read or write a field, or call a method, the object reference intercepts these requests and injects its own actions. Thus, any object access can trigger a rather complex sequence of intermediate actions which are executed behind the scenes. In large programs this hidden functionality associated with references can account for a great deal or even most of the overall complexity. The main task of CoP in this sense consists in providing adequate means for effectively describing this type of hidden intermediate functionality which has a cross-cutting nature. OOP does not provide any facilities for describing custom references and all objects are represented and accessed in one and the same way. CoP fills this gap and allows the programmer to effectively separate both concerns (Dijkstra, 1976): explicitly used business logic of objects and intermediate functions executed implicitly during object access.

The problem of indirect object representation and access can be solved by using such approaches as dynamic proxies (Blosser, 2000), mixins (Bracha & Cook, 1990; Smaragdakis & Batory, 1998), metaobject protocol (Kiczales et al., 1991; Kiczales et al., 1993), remoting via some middleware (Monson-Haefel, 2006), smart pointers (Stroustrup, 1991), aspect-oriented programming (Kiczales et al., 1997) and others. However, CoP is the only technology that has been developed for precisely this problem and solves it in a principled manner. It is important that CoP generalizes OOP by providing a possibility of smooth transfer to the new technology.

Key Terms in this Chapter

Reference Class: A class which is intended to describe structure and behavior of object identifiers. Its instances, called references, are passed by-value and indirectly represent objects by substituting for some primitive reference.

Complex Reference: A sequence of references, called segments, where each next segment represents an object within the context of the previous segment. Complex references are used to represent objects in a hierarchical address space. The format of one segment is defined by the reference class of the corresponding concept.

Dual Methods: These have the same signature but different definitions in the object class and the reference class of a concept. Dual methods are used as usual by specifying their name and parameters.

Primitive Reference: A reference provided by the compiler depending on the run-time environment. Structure and functions of primitive references cannot be changed by the programmer and therefore it is assumed that they provide direct access to objects.

Concept: A pair consisting of one object class and one reference class. Instances of the object class are referred to as objects and are passed-by-reference. Instances of the reference class, called references, are passed by-value and represent objects.

Continuation Method: A special method of the reference class which is intended to resolve this reference by translating its field values into the substituted primitive reference which can be then used for direct access.

Context Stack: A stack of resolved references to parent objects (contexts). A reference on top of the context stack provides direct access to the target object and is obtained by resolving the last (low) segment of a complex reference. A reference at the bottom is obtained by resolving the first (high) segment of the complex reference.

Complete Chapter List

Search this Book:
Reset