Архитектура ООП-класса для советника, тестера и оптимизатора

Новый комментарий
 

Изучаю ООП и прошу помощи в изобретении велосипеда.

 

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

 

Аналогично хочется определиться с архитектурой тестера. Как он должен ООП-выглядеть, чтобы в него можно было передать класс в виде советника? Или сразу несколько советников.

 

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

 

Уверен, многие такие вещи у себя делали. Поделитесь своими соображениями, или, может, ООП-болванками (без исходников) , где видна основная мысль их архитектурного построения.

 

Вероятно, что возможностей языка MQL4++ не хватает для построения подобных архитектур. Ну тогда выйдем немного за его рамки - другой ООП-язык.

 

Сначала хочется просто понять, как архитектурно все построить, проблемы реализации на каком-либо языке - вторичное.

 

На сто процентов это объезженный велосипед. Помогите не изобретать его. 

 

В принципе к классу советника требований минимум - должна быть внутри структура входных параметров. Значит в класс тестера должен передаваться указатель на базовый класс советника и указатель на структуру входных параметров.

С передачей структуры произвольного вида в MQL4++, как понимаю, ничего не получится. 

 

Тестер должен хранить текущее тестерное торговое окружение - жестко заданная структура.

 

Оптимизатор на входе должен получать массив стуктур входных параметров советников из тестера и указатель на объект тестера.

Хранить в оптимизаторе нужно как-то результаты прогона - разные варианты могут быть. 

Новый комментарий