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