Representation of an object in programming. - page 9

New comment
 
JRandomTrader #:

What are "appendices" written in?

In application languages.

 

Part 2.

In the first part we talked about the constituents of the Object, but in this part we will consider their relations to each other. The components themselves will be conventionally called"Proto-blocks", because they are not full-fledged objects, but represent some "building" entities that are part of all objects and systems. Let me remind you of their initial list:

  • Parameter - a named and numerically compressed representation of a certain structural set or value.
  • A set of properties - the list of parameters included in the Object.
  • Constructor Function- An algorithm that reproduces an Object based on a list of its parameters.
  • Shape- Combines a type of sets belonging to an Object, which exist in two or three dimensions.
  • States-significant "breakpoints" in the Object's existence, values of parameters to which the Object passes at change of environmental conditions or in the process of independent execution of a program .
  • Events - meaningful changes in the Object itself or in its surroundings.
  • Processes - various sequences of change of states of the Object(s), resulting fromchanging conditions of external environment or independent execution of a programme.

In addition to the parametric "body" of Form, State, Event and Process, we will add a handler function (let's call it simply "handler") whose task is to "transfer" values from its proto-block to the Object's parametric set. For example: a Label has 5 parameters in a constructor function and this set is its parametric "body". Suppose we have invented a new state and written it as different values of the initial parameters, and the moment we need to move the Label to a new state, we need to call a function that transfers them from the parametric structure of the State to the parametric "body" of the Label. Simply put, this handler initializes the Object parameters with the values of its proto-block. For Process and Form, similar principle works with value transferring to Object's body but the implementation is different. But to processan Event we don't need to transfer the values - we need to check them, so a condition statement will do as a handler.

There are many handlers in my concept and they deserve a separate classification, but it would complicate the presentation too much and therefore I will touch upon them superficially, roughly dividing them into several groups:

  • "Transporters" - Handlers that transfer values from a proto-block to an Object (e.g. from a State, Form, Process to an Object's target parameters).
  • "Bound" - Handlers that change values of bound (dependent) parameters in the system (e.g. - a parabolic trajectory of motion implies synchronous change of coordinate values and this is implemented by a bound x,y handler). Dependencies in parameter relationships can be expressed by formulas, or defined by conditions included in the body of the handler.
  • "Assemblers" - Handlers that "build" new proto-blocks by "unpacking" them from the Object's parametric body and saving them with the important current values, or "cloning" other proto-blocks, either partially or completely, and making the necessary changes to the copies. In this process, either tabular or hierarchical structures are formed from the proto-blocks, which are arranged within special "modules" in which they are stored.
  • "Modular" - Handlers of different types of modules in which proto-blocks are stored. *(About "modules" of the proto-blocks will be described further).

This is by no means a complete list and names of handlers are arbitrary, but the division of their specialisation, in general, looks like this.


The next addition to the concept after handler functions would be"Modules". It is logical to assume that created proto-blocks must be stored and organized somewhere, and it is also easy to guess, that it would be optimal to separate storing of proto-blocks of different types to avoid confusion and let handlers easily "navigate" through growing contents of the Object. Hence, we create "storages" or, as it is even more beautiful,"Modules" of proto-blocks. For States, Processes, Events and Forms of the object will be created their own modules in which the proto-blocks will be:

  1. Stored in an orderly manner.
  2. Multiply.
  3. Retrieve by handlers as needed.
  4. Link to proto-blocks in other Modules.

The fourth point - of "linking" proto-blocks of different types is precisely based on their "structural inclusion" into each other, which I spoke about in the first part - Process includes States,... Event includes State,... A process includes Events,... A State can include a Form, and so on... For example, if we build our event model in a separate module, then its condition hierarchy will contain Events that are stored in the 'Event' module, and these Events in turn contain States that are stored in the States module. In this way, we not only create an efficient way of storing and using proto-blocks, but we also implement their "structural inclusivity" simply by connecting them to each other with links between the modules. By arbitrarily or thoughtfully changing links, we can create new proto-blocks from existing ones, as well as change the event or logic model in the Object's "behaviour". Changing the relationships at the level of the logic model (which in turn will be stored in its module) can completely change the program, and in doing so, we do not have to rewrite anything in the code. This is where I see the advantages of modular separation of proto-blocks.

That's all for now. Next, I'll move on to event and logic models and consider how they are constructed.

Ask questions if anything is unclear or interesting.


 
What is the concept for?
 
Aliaksandr Hryshyn #:
What is the concept for?

This concept is an attempt to move to the next level of programming, which in my view will be 'building' (rather than writing) functional systems by the computer itself, rather than by humans. The software will be able to create programmes.

There is now a neural network trained on githab code, but that's not what I mean at all.

 
There's one thing I can't figure out, I set values for the trend line ObjectCreate(...), the line doesn't appear on the screen. Please help me, how to display an object?
 
Реter Konow #:

This concept is an attempt to move to the next level of programming, which in my view will be 'building' (rather than writing) functional systems by the computer itself, rather than by humans. The software will be able to create programmes.

There is now a neural network trained on githab code, but that's not what I mean at all.

Hello Peter.
Besides OOP there is also DDD(Domain-driven design)
Just to keep you informed.

 
Nikolai Semko #:

Hi Peter.
In addition to OOP, there is DDD(Domain-driven design)
Just so you know.

You're confusing the warm and the soft.

 
Andrei Trukhanovich #:

You're confusing the warm and the soft.

You're confusing hot with cold too
 
Vladimir Baskakov #:

Where's the signal, bro?

 
Andrei Trukhanovich #:

Where's the signal, bro?

Where's yours?
1234567891011121314151617
New comment