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