by Mike Sfez, Creator & Chief Strategist
Object programming approach
State of the art
Creation of object classes, called “Object”, essentially composed of Properties and Methods. A class can inherit properties and methods from other classes.
Properties can be linked (bound) to database table columns. They establish their state by applying methods selected by algorithms used as rules.
Methods are also used to produce algorithms which intelligently instantiate other classes of objects. When this is authorized, object methods can be used by other objects.
Databases store the last published state of properties linked to table columns. The latter possess their own inter-table relations, as well as access paths to table instances.
All manifestations (active wake) of object properties are managed by methods and under control of the developer, who must be aware of, and pertinently manage, the mass of affectations and perceptions of each property, concerning those who affect its own state, and/or whose state is affected by it.
The “zero” (main) class launches the first instantiation initial process.
In any case, a source code, whether written by the developer or automatically generated by the software workshop, must be maintained, complied and assembled to achieve a final product: an executable.
Remarks
Database columns can be linked to properties of different objects. In the absence of good and rigorous program writing, any such property can use different and even contradictory methods to establish its state.
The state of database information is established outside of it, according to different methods which are not known by it!
Violation of information-object free will!
Unacceptable separation between the state, and the rules and methods affecting it !
In other words, one is never sure of the coherence and truth of an information state when simultaneously published on different supports (screen, document, or database) by different objects instantiation.
The developer’s point of view is placed under the angle of a property in different object classes, while it should be under the unique angle of information, so its point of view would be globally “objective”!
Furthermore, inter-table “usage relations” of the database - induced by methods used by properties to establish their “true” state (those who affect their state) - must be explicitly established in the database without knowledge of these affects!
The developer must manage all consequences of procedural algorithms: information state affects depending on the sequence of properties manifestation.
Source code manipulation, maintenance, compilation and assembly. Reiterated tests on each modification phase.
One must achieve an exact correspondence between a database characteristics and its reflection in object class usage. Inter-table relations of the database are not discovered and established by object classes, but defined outside it by using database engine services.
Designers and developers don’t work directly on the information-object in its real manifestation form, but on its model which is distributed in various classes.
axxun Approach
State of the art
axxun proposes “business” object classes. They are presented and handled in their real and final form of manifestation.
The developer encapsulates in the “business” objects the rules and methods describing their state behavior.
The application is ready for execution!
The “business” objects of the application are stored and secured in a central application repository.
Remarks
Database tables as well as their relations are established and maintained by the axxun runtime engine in full transparency for the developer, while uniquely assuming each object state intelligence.
Inter object affectations are fully managed by the axxun runtime engine without any involvement of the developer, and in total absence of procedural algorithms and information redundancies.
Protection of object free will!
Totally “objective” developer point of view is placed under the global information angle.
- Guaranteed coherence of object state in all its publications.
- Total absence of source code: no compiling and no assembly!
- No object class reification.
- Maintenance is only reduced to modification of object behavioral rules, and then straight to immediate execution.