Мой подход. Ядро - Движок. - страница 5

 
О чём речь? Почему ядро не может содержать массив структур/классов - окно, кнопка и т.д.? (риторический).
Вы бы купили ведро радиодеталей вместо телевизора? Так же и ядру не нужно заморачиваться с деталями. Но дело ваше, раз удобно - ну и отлично.
 

Движок работает с Ядром с помощью технологии, которую я называю "Фокус элементов" (может не очень удачное название). 

Суть в следующем: 

Двигая по графику курсором, пользователь пересекает границы объектов. Каждый Элемент имеет свою территорию в пространстве графика. Специальная функция следит за координатами курсора и отмечает, на территории какого Окна и Элемента курсор находится.

Номер Окна и Элемента в Ядре, записываются в глобальные переменные. Далее, через них движок обращается к Ядру и получает все текущие значения свойств Окна, Элемента, и Объекта, на котором находится курсор.

Если происходит какое то событие, (Клик, Отжатие, Дабл-клик и т.д...), то в блоке обрабатывающем это событие, сразу ИЗВЕСТНО в каком Окне и с каким Элементом было это событие.

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

Это очень эффективно.

Именно поэтому, Ядро должно быть простым глобальным массивом.  
 
Реter Konow:

...

Именно поэтому, Ядро должно быть простым глобальным массивом.  

В природе уже давно известны массивы указателей. 

Так много усилий тратить, на изобретение велосипеда... все он уж давно есть и в на много лучшем виде.

Забавная штука это ООП - там много психологического сопротивления в людях вызывает. Даже когда не надо писать классы, а только использовать.

Зачем ограничиваться одним ядром. Если с точки зрения такого ядерного подхода, то ООП - это просто неистовый генератор ядер.

 
Dmitry Fedoseev:

В природе уже давно известны массивы указателей. 

Так много усилий тратить, на изобретение велосипеда...

Понимаете, что все это влечет использование доп. синтаксиса, в котором нет практической необходимости. Решение не требует этого синтаксиса и доп. инструментов.

Решение может быть до примитивизма просто, но ОЧЕНЬ эффективно. Именно так, я и стремлюсь сделать.

 
Dmitry Fedoseev:

Зачем ограничиваться одним ядром. Если с точки зрения такого ядерного подхода, то ООП - это просто неистовый генератор ядер.

Зачем здесь ООП, если Решение его не требует?

Окна, Элементы, Объекты представлены и упорядочены в Ядре. Обращение к ним через индекс массива или через фокус Элементов. 

Зачем указатели, ссылки, классы, конструкторы, деструкторы, и еще миллион вещей, если Решение уже есть?

Оно простое и самодостаточное.


ООП нужен совсем для другого. ООП нужен был бы, если эту технологию я создавал с коммандой других разработчиков, и каждый из нас делал только часть работы.

 
Реter Konow:

ООП нужен совсем для другого. ООП нужен был бы, если эту технологию я создавал с коммандой других разработчиков, и каждый из нас делал только часть работы.

ув. ТС ну давайте в коде примеры своих мыслей, то, что ООП это "зло", это потом обсудим... как говорится коды в студию! )))

 
  1. ООП нужен для слаженного взаимодействия комманды разработчиков, работающих над одной программой. 
  2. ООП нужен чтобы разбираться и менять код, который написан коммандой разработчиков.

НО, - ООП не нужен, когда работает один программист и его задачи не требуют применения ООП.

 
Да вы утоните в своей технологии после двухмесячного перерыва при поптке что-то допилить. А ваш конструктор, видимо, недостаточно сложен раз сложность масштабирования не стала понятной.
 
Igor Makanu:

ув. ТС ну давайте в коде примеры своих мыслей, то, что ООП это "зло", это потом обсудим... как говорится коды в студию! )))

Да, я подготовлю простые примеры.

 
Реter Konow:
  1. ООП нужен для слаженного взаимодействия комманды разработчиков, работающих над одной программой. 
  2. ООП нужен чтобы разбираться и менять код, который написан коммандой разработчиков.

НО, - ООП не нужен, когда работает один программист и его задачи не требуют применения ООП.

Оба тезиса ложны.