Представление объекта в программировании. - страница 9

Новый комментарий
 
JRandomTrader #:

А "приложеньица" на чём пишутся?

На языках приложеньицирования. 

 

Часть 2. 

В первой части мы говорили о состовляющих Объекта, а в этой рассмотрим их связи между собой. Сами состовляющие будем условно называть "Прото-блоками", ведь полноценными объектами они не являются, а представляют некие "строительные" сущности входящие в состав всех объектов и систем. Напомню их начальный список:

  • Параметр                     - именованное и сжатое в числе представление некого структурного множества или величины.
  • Набор свойств              - список параметров, входящих в состав Объекта.
  • Функция-конструктор  - алгоритм, воспроизводящий Объект на базе списка его параметров.
  • Форма                            - Объединяет тип множеств принадлежащих Объекту, которые существующие в двух или трех измерениях.
  • Состояния                     - значимые "точки останова" в бытии Объекта. Значения параметров к которым Объект переходит при изменении условий внешней среды или в процессе независимого исполнения программы.
  • События                        - значимые изменения в самом Объекте либо в его окружении.
  • Процессы                        - разные последовательности смены состояний Объекта(ов) как результат изменении условий внешней среды или независимого исполнения программы.

В дополнение к параметрическому "телу" Формы, Состояния, События и Процесса добавим функцию-обработчик (назовем ее просто "обработчик"), задача которой "переносить" значения из своего прото-блока в параметрический набор Объекта. Например: Метка имеет 5 параметров в функции-конструкторе и этот набор есть ее параметрическое "тело". Допустим, мы придумали новое состояние и записали его в виде иных значений исходных параметров, и в момент когда нам нужно перевести Метку в новое состояние, мы должны вызвать функцию которая перенесет их из параметрической структуры Состояния в параметрическое "тело" Метки. Проще говоря, этот обработчик инициализирует параметры Объекта значениями своего прото-блока. Для Процесса и Формы работает похожий принцип с переносом значений в тело Объекта, но реализация иная. А вот для обработки События не нужно переносить значения - их нужно проверять, а значит в качестве обработчика подойдет оператор условия.

Надо сказать, в моей концепции обработчиков много и они заслуживают отдельной классификации, но это слишком усложнит изложение и потому коснусь их поверхностно, условно разделив на несколько групп:

  • "Транспортеры" - Обработчики, переносящие значения из прото-блока в Объект (например из Состояния, Формы, Процесса в целевые параметры Объекта).
  • "Связные"           - Обработчики, меняющие значения связанных (зависимых) параметров в системе (например - параболическая траектория движения подразумевает синхронное изменение значений координат и это реализуется связывающим параметры х,у обработчиком). Зависимости в связях параметров могут быть выражены формулами, либо определены условиями входящими в тело обработчика.
  • "Сборщики"     - Обработчики, "строящие" новые прото-блоки "отпачковывая" их от параметрического тела Объекта и сохраняя с важными текущими значениями, либо "клонируя" другие прото-блоки, частично или целиком, и внося в копии нужные изменения. В этом процессе формируются либо табличные, либо иерархические структуры из прото-блоков которые упорядочиваются внутри специальных "модулей" в которых они хранятся. 
  • "Модульные"   - Обработчики модулей различных типов в которых хранятся прото-блоки .   *(О "модулях" прото-блоков будет рассказано далее).

Это далеко не полный список и названия типов обработчиков условны, но разделение их специализации, в целом, имеет такой вид.


Следующим дополнением к концепции после функций-обработчиков будут "Модули". Логично предположить, что создаваемые прото-блоки должны где-то храниться и упорядочиваться и также легко догадаться, что оптимальным будет разделение храниения прото-блоков разных типов чтобы избежать путаницы и дать возможность обработчикам легко "ориентироваться" внутри растущего содержания Объекта. Следовательно, создаем "склады" или, как их еще более красиво, - "Модули" прото-блоков. Для Состояний, Процессов, Событий и Форм объекта будут созданы свои модули в которых прото-блоки будут:

  1. Упорядоченно храниться.
  2. Множиться.
  3. Извлекаться обработчиками при необходимости.
  4. Связываться с прото-блоками в других Модулях.

Четвертый пункт - "связывания" прото-блоков разных типов как раз базируется на их "структурной включаемости" друг в друга, о которой я говорил в первой части - Процесс включает Состояния,... Событие включает Состояние,... Процесс включает События,... Состояние может включать Форму, и так далее... Например, если мы строим событийную модель в отдельном модуле, то иерархия ее условий будет содержать События, которые хранятся в "Событийном" модуле, а эти События, в свою очередь, содержат Состояния которые хранятся в модуле Состояний. Таким образом, мы не только создаем эффективный порядок хранения и использования прото-блоков, но и реализуем их "структурную включаемость" просто соединяя их между собой связками между модулями. Произвольно или продуманно меняя связи мы можем создавать как новые прото-блоки из уже имеющихся, так и менять событийную или логическую модель в "поведении" Объекта. Изменение связей на уровне логической модели (которая, в свою очередь будет храниться в своем модуле) может полностью изменить программу и при этом, нам не нужно ничего переписывать в коде. В этом я вижу преимущества модульного разделения прото-блоков.

Пока все. Далее, перейду к событийным и логическим моделям и рассмотрю как они строятся.

Задавайте вопросы если что то непонятно или интересно.


 
Для чего эта концепция?
 
Aliaksandr Hryshyn #:
Для чего эта концепция?

Эта концепция является попыткой перейти к программированию следующего уровня, которое, на мой взгляд, будет "построением" (а не написанием) функциональных систем самим компьютером, а не человеком. Программа сможет создавать программы.   

Сейчас существует нейросеть обученная на коде гитхаба, но это совсем не то, что имею ввиду.

 
Я вот с одним не могу разобраться, я устанавливаю значения для трендовой линии ObjectCreate(...), линия не выводится на экран. Помогите пожалуйста, как вывести на экран объект?
 
Реter Konow #:

Эта концепция является попыткой перейти к программированию следующего уровня, которое, на мой взгляд, будет "построением" (а не написанием) функциональных систем самим компьютером, а не человеком. Программа сможет создавать программы.   

Сейчас существует нейросеть обученная на коде гитхаба, но это совсем не то, что имею ввиду.

Привет, Петр.
Кроме ООП еще существует DDD (Domain-driven design)
Просто чтоб был в курсе.

 
Nikolai Semko #:

Привет, Петр.
Кроме ООП еще существует DDD (Domain-driven design)
Просто чтоб был в курсе.

Путаешь теплое с мягким.

 
Andrei Trukhanovich #:

Путаешь теплое с мягким.

Ты и горячее с холодным путаешь
 
Vladimir Baskakov #:

Где сигнал, бро?

 
Andrei Trukhanovich #:

Где сигнал, бро?

Где твой?
1234567891011121314151617
Новый комментарий
Причина обращения: