IRMA-International.org: Creator of Knowledge
Information Resources Management Association
Advancing the Concepts & Practices of Information Resources Management in Modern Organizations

Concept-Oriented Programming

Concept-Oriented Programming
View Sample PDF
Author(s): Alexandr Savinov (University of Bonn, Germany)
Copyright: 2009
Pages: 9
Source title: Encyclopedia of Information Science and Technology, Second Edition
Source Author(s)/Editor(s): Mehdi Khosrow-Pour, D.B.A. (Information Resources Management Association, USA)
DOI: 10.4018/978-1-60566-026-4.ch109

Purchase

View Concept-Oriented Programming on the publisher's website for pricing and purchasing information.

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.

Related Content

Christine Kosmopoulos. © 2022. 22 pages.
Melkamu Beyene, Solomon Mekonnen Tekle, Daniel Gelaw Alemneh. © 2022. 21 pages.
Rajkumari Sofia Devi, Ch. Ibohal Singh. © 2022. 21 pages.
Ida Fajar Priyanto. © 2022. 16 pages.
Murtala Ismail Adakawa. © 2022. 27 pages.
Shimelis Getu Assefa. © 2022. 17 pages.
Angela Y. Ford, Daniel Gelaw Alemneh. © 2022. 22 pages.
Body Bottom