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

[Aliaksandr Hryshyn]

ООП не мешает реализации ядра, даже наоборот.

Обычно есть код и данные. Ядро, в нашем случае, это код, сильно отделённый от данных. В качестве данных может быть и сам код. Ядро обычно имеет более полный функционал для работы с конкретными данными, или, хотя бы, некоторый самодостаточный минимум.

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

Вот ещё пример, где можно применять такой подход: есть куча стратегий в советнике, в качестве данных выступает только логика стратегий, ядром является функционал по управлению ими, а конкретно управление ордерами, рисками, работа с торговым окружением, индикаторами, обработка ошибок, вывод статистики по отдельности или общей, функции трейлинга/сеток/.....

[Alexey Navoykov]

Реter Konow:

Вы создаете массив и записываете в него значения свойств кнопки которую хотите создать

Кнопка состоит из трех объектов: Основание, Текст, Картинка.

Каждый объект существует внутри Элемента кнопки, следовательно, массив должен быть двумерным.

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

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

Вот пример:

struct TObject { char type;  string name;  int x;  int y;  int width;  int height;  color clr; };

TObject Objects[]= { { OBJ_BITMAP, "Bitmap", 100, 100, 200, 200, clrRed },
                     { OBJ_BUTTON, "Button", 150, 150, 50, 10, clrWhite },
                   };

[Maxim Kuznetsov]

Alexey Navoykov:

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

тут как-бы двояко.. что лучше -  массив структур или структура массивов ?

но MQL заточен под работу с фортрановскими массивами, это факт..

[Alexey Navoykov]

Maxim Kuznetsov:

тут как-бы двояко.. что лучше -  массив структур или структура массивов ?

О какой структуре массивов речь?  У автора просто массивы  

[Petros Shatakhtsyan]

Я думаю, что Peter никогда не видел как на Visual C++ создается шаблон DialogBox, в визуальном режиме перетащится туда любые Controls, такие как Button, CheckBox, EditBox, ComboBox и т.д.

Т. е. те элементы которые есть в Windows, в том числе разные возможности для отображения строк DB с возможностью корректировки полей и строк.

И с использованием MFC можно за несколько минут и очень кратко сделать довольно сложных диалоговых окон.

[Реter Konow]

Alexey Navoykov:

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

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

Вот пример:

Красивое решение. Но эта структура не может быть интегрирована в Ядро. Если при построении Ядра по моей технологии, нужно просто делать цикл по массиву с прототипами элементов и переписывать их в Ядро, то в случае Вашего решения, - цикл невозможен.

Хотя, может и возможен, но заворачивать каждый элемент в отдельную структутру... И как это вывести на глобальную область? Где это все объявлять... Непонятно. 

У меня все просто. Массив прототипов элементов. Все свойства объектов внутри него. Сам массив - глобальный. Доступ наипростейший и из любой точки программы.

[pavlick_]

А ваше нутро не сопротивляется при использовании даблов? Ведь это тоже составной объект со своими методами. Нет им места в православных массивах ядра! Посмотрите, ведь впечатляет (мантисса, экспонента, знак):

_NEW_OBJECT, тра-та-та-та-та-та, 3, 10, 1, тра-та-та-та-та-та

[Реter Konow]

pavlick_:
А ваше нутро не сопротивляется при использовании даблов? Ведь это тоже составной объект со своими методами. Нет им места в православных массивах ядра! Посмотрите, ведь впечатляет (мантисса, экспонента, знак):

Ничего не понял.

[Реter Konow]

Избавившись от лишнего синтаксиса и танцев с бубном, я просто инициализирую свойства элементов в глобальном массиве прототипов.

Он используется только один раз, - когда прототипы элементов переписываются в Ядро.

Переписывание осуществляется в простом цикле.  

В итоге, на этапе построения, Ядро начинает содержать в себе прототипы выбранных пользователем элементов.

Далее, начинаются новые циклы по Ядру. В них я записываю пользовательские значения свойств элементов.

В конце, получается готовое Ядро, которое содержит готовые пользовательские окна со всеми элементами.

[Реter Konow]

Выше описанный процесс, я называю "процессом построения Ядра".

После построения Ядра, начинает работать "движок".

Движок - код, который управляет механикой элементов.

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