Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А "приложеньица" на чём пишутся?
На языках приложеньицирования.
Часть 2.
В первой части мы говорили о состовляющих Объекта, а в этой рассмотрим их связи между собой. Сами состовляющие будем условно называть "Прото-блоками", ведь полноценными объектами они не являются, а представляют некие "строительные" сущности входящие в состав всех объектов и систем. Напомню их начальный список:
В дополнение к параметрическому "телу" Формы, Состояния, События и Процесса добавим функцию-обработчик (назовем ее просто "обработчик"), задача которой "переносить" значения из своего прото-блока в параметрический набор Объекта. Например: Метка имеет 5 параметров в функции-конструкторе и этот набор есть ее параметрическое "тело". Допустим, мы придумали новое состояние и записали его в виде иных значений исходных параметров, и в момент когда нам нужно перевести Метку в новое состояние, мы должны вызвать функцию которая перенесет их из параметрической структуры Состояния в параметрическое "тело" Метки. Проще говоря, этот обработчик инициализирует параметры Объекта значениями своего прото-блока. Для Процесса и Формы работает похожий принцип с переносом значений в тело Объекта, но реализация иная. А вот для обработки События не нужно переносить значения - их нужно проверять, а значит в качестве обработчика подойдет оператор условия.
Надо сказать, в моей концепции обработчиков много и они заслуживают отдельной классификации, но это слишком усложнит изложение и потому коснусь их поверхностно, условно разделив на несколько групп:
Это далеко не полный список и названия типов обработчиков условны, но разделение их специализации, в целом, имеет такой вид.
Следующим дополнением к концепции после функций-обработчиков будут "Модули". Логично предположить, что создаваемые прото-блоки должны где-то храниться и упорядочиваться и также легко догадаться, что оптимальным будет разделение храниения прото-блоков разных типов чтобы избежать путаницы и дать возможность обработчикам легко "ориентироваться" внутри растущего содержания Объекта. Следовательно, создаем "склады" или, как их еще более красиво, - "Модули" прото-блоков. Для Состояний, Процессов, Событий и Форм объекта будут созданы свои модули в которых прото-блоки будут:
Четвертый пункт - "связывания" прото-блоков разных типов как раз базируется на их "структурной включаемости" друг в друга, о которой я говорил в первой части - Процесс включает Состояния,... Событие включает Состояние,... Процесс включает События,... Состояние может включать Форму, и так далее... Например, если мы строим событийную модель в отдельном модуле, то иерархия ее условий будет содержать События, которые хранятся в "Событийном" модуле, а эти События, в свою очередь, содержат Состояния которые хранятся в модуле Состояний. Таким образом, мы не только создаем эффективный порядок хранения и использования прото-блоков, но и реализуем их "структурную включаемость" просто соединяя их между собой связками между модулями. Произвольно или продуманно меняя связи мы можем создавать как новые прото-блоки из уже имеющихся, так и менять событийную или логическую модель в "поведении" Объекта. Изменение связей на уровне логической модели (которая, в свою очередь будет храниться в своем модуле) может полностью изменить программу и при этом, нам не нужно ничего переписывать в коде. В этом я вижу преимущества модульного разделения прото-блоков.
Пока все. Далее, перейду к событийным и логическим моделям и рассмотрю как они строятся.
Задавайте вопросы если что то непонятно или интересно.
Для чего эта концепция?
Эта концепция является попыткой перейти к программированию следующего уровня, которое, на мой взгляд, будет "построением" (а не написанием) функциональных систем самим компьютером, а не человеком. Программа сможет создавать программы.
Сейчас существует нейросеть обученная на коде гитхаба, но это совсем не то, что имею ввиду.
Эта концепция является попыткой перейти к программированию следующего уровня, которое, на мой взгляд, будет "построением" (а не написанием) функциональных систем самим компьютером, а не человеком. Программа сможет создавать программы.
Сейчас существует нейросеть обученная на коде гитхаба, но это совсем не то, что имею ввиду.
Привет, Петр.
Кроме ООП еще существует DDD (Domain-driven design)
Просто чтоб был в курсе.
Привет, Петр.
Кроме ООП еще существует DDD (Domain-driven design)
Просто чтоб был в курсе.
Путаешь теплое с мягким.
Путаешь теплое с мягким.
Где сигнал, бро?
Где сигнал, бро?