Используете ли вы CExpert при создании роботов? - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как на MQL4 писали ТС?! Для чего матрешки-то такие с ООП-наследованием?
Задумался, а может пишу советники совсем не так, как тут озвучивают. Может, совсем по-другому представляю архитектуру советника.
Читаешь и думаешь - ради чего столько городят? Ну не ООП же ради ООП.
Сам ООП и наследования использую во всю. Но чтобы городить какие-то умопомрачительные матрешки при написании ТС... не понимаю.
И да, совершенно не представляю ТС в виде конструктора. Типа, не было трейлинга. Захотелось добавить - добавил соответствующий объект, отвечающий за трейлинг, и вот он уже работает.
Наверное, во фрилансе для заказчиков, у которых семь пятниц на неделе (не знают, что хотят), это оправдано. Но если для себя пишешь, какой нафиг трейлинг там, где по логике он не должен быть просто. Какие еще кубики и конструкторы. Типа, если кубики особенным образом перемешать, то робастность появится? Нафиг такие детские представления.
Ни одной ТС из кубиков не написал. И написал-то меньше 10 штук. Потому что это не Лего, а идеи. Вдумчивые, с пониманием и некоторым обоснованием. ТС - это не "лего".
Как на MQL4 писали ТС?! Для чего матрешки-то такие с ООП-наследованием?
Задумался, а может пишу советники совсем не так, как тут озвучивают. Может, совсем по-другому представляю архитектуру советника.
Читаешь и думаешь - ради чего столько городят? Ну не ООП же ради ООП.
И ООП, и "матрешки" в ТС - очень даже оправдывают себя при дальнейшей поддержке кода.
Когда эксперт умещается на одну страницу кода - городить структуру на основе ООП - неразумно.
Однако, когда эксперт сложен (скажем, у меня есть эксперт, которые использует двадцать паттернов, плюс уровни, плюс трендлинии) - ООП-структура позволяет вносить изменения в код с минимальной вероятность внесения дополнительных ошибок.
..."матрешки" в ТС - очень даже оправдывают себя при дальнейшей поддержке кода.
...
И да, совершенно не представляю ТС в виде конструктора. Типа, не было трейлинга. Захотелось добавить - добавил соответствующий объект, отвечающий за трейлинг, и вот он уже работает.
У меня это реализовано следующим образом, в классе CMyAdvisorPartsFactoryT есть метод _CreateSLTPTrailingDefiner() - именно он создает объект, который определяет трейлинг. Если нам не нужен трейлинг - мы просто не переопределяем этот метод, по умолчанию он возвращает NULL, и фабрика после инициализации, вызывая этот метод - поймет, что трейлинга нет. Потом, эксперт (потомок от CExpert) запросит у фабрики указатель на трейлинг-дефайнер, получит этот самый NULL, поймет, что трейлинга нет - и в классе CMyTrailingT (наследнике от класса трейлига в СБ) в соответствующих функциях трейлинг применяться не будет.
Если трейлинг нужен, и у нас уже есть подходящий трейлинг-дефайнер, то переопределяем указанную функцию:
virtual CSLTPTrailingDefinerT* _CreateSLTPTrailingDefiner(SDRInitData & rdidInitData){ return( new CShrinkTPSLTrailingDefiner(rdidInitData)); };
После этого указанный объект будет создан при инициализации фабрики, а когда эксперт запросит указатель на трейлинг-дефайнер - будет возвращен указатель на созданный объект.
В классе CMyTrailingT, в соответствующих функциях трейлинга, при определении значений трейлинга - они будут получены у созданного объекта.
Если нам понадобится другой трейлинг-дефайнер - просто переписываем указанную функцию, вместо CShrinkTPSLTrailingDefiner - создаем какой-нибудь CSuperTPSLTrailingDefiner (понятное дело, если его нет - надо отдельно написать код этого класса)
Матрешки - это всегда адовое зло. Наследование вообще очень опасная концепция в ООП, не даром в современных языках от него стараются отойти в сторону более простых интерфейсов.
Боюсь это объясняется тем, что современным программистам редко нужно поддерживать код.
А я - неоднократно сталкивался с ситуацией, когда хорошо продуманная система классов-матрешек очень помогает в дальнейшем поддерживать код, когда не надо детально вспоминать все тонкости работы большого класса, достаточно вспомнить ту "матрешку", в которой потребовалось изменение.
Ну а насчет "более простых интерфейсов" - это общее правило программирования. Я вот даже оператор "вопросик" не люблю по этой причине, заменяя его оператором if - читается проще, а исполняемый код получается практически одинаковый.
ТС - это не "лего".
Вот об этом был основной посыл моего негодования.
А я от двух или даже больше вроде как достаточно успешных трейдеров слышал обратное - ошибка считать ТС - целостной системой. На самом деле ТС - это вот именно "конструктор Лего", в котором каждая часть - это самостоятельная техника, которая должна проверяться самостоятельно. И лишь если в самой простейшей, "схематичной" ТС данный "кубик" показывает профитные результаты - только в этом случае его можно использовать для реальной рабочей ТС.
А в этом случае - принципы ООП - очень даже подходят. Другое дело, нужен ли общий каркас советника, основанный на CExpert (или другом, аналогичном классе) или нет.
А я от двух или даже больше вроде как достаточно успешных трейдеров слышал обратное - ошибка считать ТС - целостной системой. На самом деле ТС - это вот именно "конструктор Лего", в котором каждая часть - это самостоятельная техника, которая должна проверяться самостоятельно. И лишь если в самой простейшей, "схематичной" ТС данный "кубик" показывает профитные результаты - только в этом случае его можно использовать для реальной рабочей ТС.
А я от двух или даже больше вроде как достаточно успешных трейдеров слышал обратное - ошибка считать ТС - целостной системой. На самом деле ТС - это вот именно "конструктор Лего", в котором каждая часть - это самостоятельная техника, которая должна проверяться самостоятельно. И лишь если в самой простейшей, "схематичной" ТС данный "кубик" показывает профитные результаты - только в этом случае его можно использовать для реальной рабочей ТС.
А в этом случае - принципы ООП - очень даже подходят. Другое дело, нужен ли общий каркас советника, основанный на CExpert (или другом, аналогичном классе) или нет.
Ни одной ТС из кубиков не написал. И написал-то меньше 10 штук. Потому что это не Лего, а идеи. Вдумчивые, с пониманием и некоторым обоснованием. ТС - это не "лего".
ошибка считать ТС - целостной системой. На самом деле ТС - это вот именно "конструктор Лего", в котором каждая часть - это самостоятельная техника, которая должна проверяться самостоятельно. И лишь если в самой простейшей, "схематичной" ТС данный "кубик" показывает профитные результаты - только в этом случае его можно использовать для реальной рабочей ТС.
Походу в терминологии заблудились - один про зелёное, другой про крашеное. Один считает кубик ТСом, другой - методом. Ну считайте ваши 10 стратегий 10ю методами, их совокупность - стратегией и всё войдёт в рамки
Насчёт лего наверное он имел в виду, что абсолютное большинство сочинителей ТС по сути игроки, а не трейдеры - озабочены подбором выигрышных комбинаций без попыток понять откуда что берётся. Но стандартная библиотека в этом не виновата :)