1. Separation of business methods (BMs) and representation and access (RA) methods. Business methods are target methods of objects which are called explicitly in the source code. Representation and access methods are called implicitly when objects are being accessed. In other words, when some BM is called a sequence of some RA methods is executed behind the scenes and hence RA methods represent a hidden layer of functionality. A programming paradigm should provide means for describing both types of functionality.
2. Objects live in spaces and any BM call has to intersect a sequence of borders in order to access the object. When an access request intersects a space border on its way to the target object some intermediate RA functionality is triggered automatically and implicitly. This hidden intermediate functionality concentrated on space borders accounts for a great deal and even most of the system complexity. Describing this functionality is as important as describing target BMs.
3. The spaces where objects live have a hierarchical structure. This structure is precisely what is called physical structure in the concept-oriented data model. Thus an object has an environment where it lives; this environment has its own environment and so on up to the root of the (physical) hierarchy.
4. Transparency of access. Here the idea is that BMs should be called impendent of the target object representation and access mechanism and the object real position. All these peculiarities should be hidden because they belong to another layer of functionality. On the other hand, since instant call is only a useful abstraction it is necessary to provide a mechanism for specifying what happens behind the scenes. Thus the illusion of instant access is provided along with means for describing intermediate functionality that belongs to the hidden RA layer and activated automatically.
Comment feed for this post
